Research in Natural Hazards Engineering > Uncertainty Quantification (quoFEM)

Parallel execution on a Windows HPC

<< < (5/5)

Sang-ri:
Hi,

Thanks for sharing the file. We are still struggling to identify the issue. From my understanding, the automated process of overwriting the evaluation_concurrency value is exactly the same as the process we tried manually, as shown below.


--- Quote from: Sang-ri on July 06, 2023, 08:37:10 PM ---Hi,

Thank you for the info. We think this number should be 128 instead of 64. While we figure out the solution, can you try the following workaround and let us know if this makes CPU occupied 100%?

1. Modify the number after "asynchronous evaluation_concurrency" in dakota.in from 64 to 128
2. Remove all files and folders in the local working directory except for "dakota.in" and "templatedir"
3. Find the path of the Dakota executable from the preference window of quoFEM. Let us denote this {dakota path}
4. Open the command prompt, cd into the folder where dakota.in is located, and type "{dakota path} dakota.in" (without the quotation marks)

It will run the forward propagation analysis, and the results will be shown in dakotaTab.out.

Thank you,
Sang-ri

--- End quote ---

Regarding this, is it possible that when we manually tried, dakotaTab.out file was not properly created even though the CPU was occupied 100%? Sorry, I should have asked this earlier.

If unsure, please just let me know. We will continue investigating the issue on our side.

Thanks,
Sang-ri

rsam1993:
Honestly I do not remember if the dakotaTab.out was properly created when we did everything manually. Let me try it again and keep you posted.

rsam1993:
I have bad news,

I ran Dakota through the command prompt as you taught me before with 128 samples. During the analysis, the CPU is 100% occupied but I get an empty dakotaTab.out at the end, and the same error in the terminal (please see the attached screenshot). But there is no dakota.err file in the directory.

Sang-ri:
Thank you so much for revisiting the previous tests! The test was immensely helpful as it clarified that the limitation comes from the UQ engine rather than the interface.

I apologize for the late reply - I was out of the office last week. In the meantime, our team made some effort to find a workaround, but unfortunately, we could not find an immediate solution, especially without being able to reproduce the error. Also, the source of issue is related to the internal function of Dakota program, which is slightly beyond SimCenter's development focus. It seems like we cannot provide a solution at this point.

However, we will keep you posted in case of further updates.

Thanks again,
Sang-ri

rsam1993:
Hi,

Thanks for teh update. I believe I should be still able to use the interface and call all the 128 cores, so the sampling and opensees analyses will be done and then using those results, I should be able to calculate the mean, standard deviation and other outputs separately.

But, hopefully, this issue can be fixed at some point.

Navigation

[0] Message Index

[*] Previous page