Molflow+ 2.9.26 run the Vacuum COST gitlab page’s default model exists some issues.
1、Compare to old version,like 2.9.25 2.9.5, et al., 2.9.26 complete simulation less than 2 min on my laptop. However, 2.9.25 and other versions is 10min. And using 2.9.26, CPU usage is less than 40%,other versions is 100%.
2、When simulaion complete, molflow 2.9.26 can’t open iteration models in “Iteration” folder, with error below
Hello, Wang!
Thank you for reporting these issues.
Version 2.9.26 does indeed perform better than older versions. I can maybe discuss the reason for such a speedup with my colleagues and write back if we discover what specifically causes such an improvement. Anyway, if possible, we recommend to always use the latest version since it is the most reliable one.
As for opening the models, there is a problem with loading empty user metadata. We appreciate you pointing this out and will fix this for the next release. For now, as a “workaround”, you can perform the following steps:
- use version 2.9.25 to generate the “Iteration” models, since this version does not generate user metadata (although it will last a bit longer, as you mentioned);
- after generating, switch to 2.9.26 and use this version to load the models; if you change the models and save them afterwards using 2.9.26, loading them again should work without problems.
Hello Petar,
Thank you for your quick reply.
With your suggestion, I am now able to open the iteration in version 2.9.26. However, the iteration models generated by the “change-save-model” run in 2.9.26 still cannot be opened in the 2.9.26.
My current solution is to run the simulation in 2.9.26 for efficiency, and then open the iteration models in 2.9.25.
I look forward to the next release.
Best regard!
Hello Wang,
We had a look with Petar, after he has tested your use case.
2.9.26 runs “faster” because iterations return an error and simulations don’t actually happen.
We have looked into the issue and in fact, VacuumCost has an XML parsing bug that affects 2.9.26 but not earlier versions. So we’d ask you to use Molflow 2.9.25 and earlier with VacuumCOST.
Petar will have a look if VacuumCOST can be fixed, but it wasn’t written by us, and we don’t know how difficult it would be.
Thanks for your patience, Marton
Hello again, Wang,
We modified the VacuumCOST to address the existing issues. It should now work regardless of the MolFlow version. The updated version of the repository is available at https://gitlab.cern.ch/molflow_synrad/vacuumcost. There is one additional dependency that has to be installed: lxml. You can also install the whole requirements.txt to automatically add all the dependencies, as described in the README.
Feel free to write again if any new problems arise.
Cheers!
Hello,
Thank you for updating VacuumCOST so quickly. The default model now runs fine on molflow2.9.26. However, I believe some issues are not fully resolved for the following reasons:
-
- After changing
"facet_inactive_selection_group_names"
, the scripts run “faster” again, but the CPU is not being utilized.
- After changing
-
- When using another model, the same issue occurs.
Looking forward to your response.
Cheers, and Merry Christmas!
Dear Wang,
Let’s try to solve the facet_inactive_selection_group_names
problem first. I tried recreating it, but the execution time in my case did not change compared to the original version. This means that each iteration executed for the amount of time specified by the scripts (file Run_simulation.py
, line 225; the execution time is specified by the cpu_time_per_iter
). Is the facet_inactive_selection_group_names
variable the only thing that was changed in your case? If not, could you please clone the repo again, update only this variable the way shown in your screenshot and check if the scripts run “faster” once more (without changing the default model)? This could help us narrow down the problem.
Thank you and Merry Christmas to you too!
Hello,
I cloned the repository again, and you are right—just changing 'facet_inactive_selection_group_names'
did not cause any bugs. However, when I add a selection group in MolflowGUI, without making any other changes(both GUI and scripts), bugs start to appear. I suspect that using my own model might trigger the same issue when modifying the selection group in the default model within MolflowGUI.
I’ve recorded a video to show the problem.
Could you please check that the CLI path in the script and the MolFlow GUI you are using to add a selection group are from the same version of MolFlow? I managed to recreate the problem only when I used the most recent MolFlow version (an artifact, not yet released) for GUI, and an older version for the CLI. Even using 2.9.26 for both could cause a problem, e.g. if you downloaded the CLI from the MolFlow releases and the GUI from the artifacts.
If you indeed used different versions, you should try using only one. The problems with VacuumCOST scripts were fixed so it should work regardless of the MolFlow version you choose, as long as you use the same one for both the GUI and the CLI. However, if possible, it is best to use the updated version from here (the artifacts column), since it includes all the changes we added based on your recent posts.
If you did, however, use the same version for the GUI and the CLI, could you do the following:
- tell us exactly what version it was (the number of the version, and whether it is an official release or an artifact),
- run the following command from a terminal:
<path_to_molflowCLI> --file <path_to_the_model_after_adding_selection_group> -t 10 --reset
, and - send us the error reported in the terminal after executing the above command.
Cheers,
Petar
Hello,
I used two versions to test the problem. One is the most recent version (artifacts) , which I named it 2.9.26-1009f06b , the other is molflow release 2.9.26. After testing different version combinations, I found its a rather strange issue.
1. Default VacuumCOST Model
Column 1 | Column 2 | Column 3 |
---|---|---|
Add selection group GUI version | VacuumCost CLI version | Error? |
2.9.26 | 2.9.26 | no |
2.9.26 | 2.9.26-1009f06b | no |
2.9.26-1009f06b | 2.9.26-1009f06b | no |
2.9.26-1009f06b | 2.9.26 | yes |
2. Custom Model
Column 1 | Column 2 | Column 3 |
---|---|---|
Add selection group GUI version | VacuumCOST CLI version | Error? |
2.9.26 | 2.9.26 | no |
2.9.26 | 2.9.26-1009f06b | no |
2.9.26-1009f06b | 2.9.26-1009f06b | no |
2.9.26-1009f06b | 2.9.26 | yes, and one more error—— model can’t open with error: invalid string position |
- After running the command
<path_to_molflowCLI> --file <path_to_the_model_after_adding_selection_group> -t 10 --reset
with GUI version 2.9.26-1009f06b and CLI version 2.9.26, I encountered the following error:
Initializer::initFromFile error: invalid string position
Other combinations with no error.
Here are my models built with versions 2.9.26 and 2.9.26-1009f06b. My model uses a constant outgassing type, with runtypes set to [3], and no inactive selection groups.
Cheers!
Model_molflow_2.9.26.zip (107.2 KB)
Model_Molflow_1009f06b.zip (403.4 KB)
sef.STL (7.5 KB)
Hello Wang,
Thank you for such a detailed analysis!
The problem occurs because of the way User Metadata is handled in the XML format once the model is saved. The release version can load the metadata from XML only if it was also saved using the release version, because it expects a very specific format. If it cannot handle the XML properly, an error occurs. When you invoke the CLI (either manually from terminal, or through the VacumCOST scripts) it has to first load the model, but sometimes fails to do so, and you get an error. We later fixed this to enable loading XML in general cases. This is why:
- the release CLI will work only with the release GUI (first rows in your tables),
- the release CLI will fail if the model was modified using the artifacts GUI (last rows in the tables), and
- the artifacts CLI will work regardless of the GUI version.
Cheers,
Petar
Hello Petar,
Thank you for the clear explanation and excellent work! I now fully understand the problem.
Cheers,
Wang