Loading of workbench .dat file via mapdl.input() slow

[Jaar00n]

I am currently experimenting with a python tool, that can load an existing model (.dat file) generated in Ansys Mechanical using the mapdl.input() function.

Once loaded into mapdl, I am using pyMAPDL comments to do scoping and exporting of certain model results.

It generally works fine, but the loading of the .dat file seems to take a very long time when working with a larger model. Does anybody know what the reason for this could be? Does the mapdl.input() command issue a rerun of the simulation?

[mikerife]

Hi @Jaar00n
Well, mapdl.input() does not issue anything so no, it (input command) is not rerunning the solve. WB Mechanical does write APDL commands to *get the 'interactive' state of MAPDL and write a *if/then statement to determine whether to bypass the solve command or not. If the state is 'interactive' then it bypasses, if not it will solve. MAPDL aaS that PyMAPDL launches is a interactive instance in this regard.

The PyMAPDL 'Input' is not the same as the APDL '/input' command. It's an new method for inputting into MAPDL aaS - see the following: https://mapdl.docs.pyansys.com/version/stable/mapdl_commands/session/_autosummary/ansys.mapdl.core.Mapdl.input.html#input

I think you can revert back to the original APDL /input command using the "orig_cmd = /inpu" option. I really don't ever use pre-built FEMs so I'm not sure about the performance of the PyMAPDL input versus APDL /input. It would be interesting if you could time its use and compare to MAPDL running interactively (with the GUI) and using /input to read in the file.

Just how large of a ds.dat file are we talking here? If you can't run the timing tests can you share the model so I can here?

Mike

[mikerife]

Hi @Jaar00n
Yeah, with the PyMAPDL 'non_interactive' I think they mean the Python side. The run-mode of MAPDL aaS does not change. Mike

[germa89]

Hi all,

I don't think we can do anything regarding the "interactivity" of MAPDL. Hence, you will always execute the solve (I will double test tomorrow this).

The easiest option is:

input_path = "/path/to/ds.dat"
with open(input_path, "r") as fid:
    input_str = fid.read()
input_str = input_str.replace("SOLVE", "!SOLVE")

mapdl.input_strings(input_str)

I will study the possibility to add an option in the input function to bypass solve.

[Jaar00n]

Hi @germa89,

thanks for the help!

I tried your suggestion. It seems to work as intended, skipping the solve. but now I get an error when trying to access the .rst file:

Error in instance GRPC_127.0.0.1:50052

*** ERROR *** CP = 4.875 TIME= 14:56:19
An error occurred while attempting to open the results file file.rst.

[germa89]

I believe if you haven't solved the model, there will be no results (file.rst file).

Depending on the amount of post processing you might need to solve.

Assuming a standard ds.dat file generated by workbench (where the SOLVE is almost at the end), you can follow this approach:

1. You run the full model, solving. An RST file is generated.
2. Use the function mapdl.download to download (if in a non-local session) / copy (if working locally) the RST file to your working directory. You could even specify a different directory to download the file. But then you need to update/change the rst_file_path variable in the following code snippet.

For the following attempts, you should do:

1. Replace the SOLVE command by !SOLVE.
2. Run the model. You might get the error you mentioned. This is fine.
3. Read the RST file doing:

   rst_file_path = os.getcwd()
   mapdl.file(os.path.join(rst_file_path, "file.rst"))

4. Perform post-processing.

Let me know if this approach works for you!

[Jaar00n]

@germa89

I did have a result file, because the model was previously solved in workbench.
The mapdl.file does the trick and links the previous result.

Thank you this works fabulous now!