Modular implementation of pre-processing, solution and post-processing

[kp3393]

Dear community,
I'm working on a project where I would like to implement three different functions, namely

1. pre_processing( ):- which will create geometries and meshing.
2. solution( ):- apply boundary conditions to the created model
3. post-processing( ):- analysis of the results for the given boundary condition

One of the motivations behind this modular implementation is to be able to create a model once (using function pre_processing( )) and then apply different boundary conditions to the model and evaluate the results. At present, the solution I came up with is to save a .db file using mapdl.save( ) in pre_processing( ). However, saving a .db file for many different models is an inefficient way.

So my question is, what should be the return value of pre_processing( ), which can be passed as a parameter to the solution( ) thus, helping in solving the model for different boundary conditions? Is something like this possible?

Thank you.

[natter1]

Interesting, I would also like to know if something like that would be possible. I guess your pre_processing() is time-consuming? Do you have considered non_interactive mode to speed things up? Otherwise you could pass pre_processing itself to solution(). That's basically what I'm doing up till now (I do use some classes for preprocessing, e.g. for certain geometries, a meshing-class, material_classes ...).

[akaszynski]

However, saving a .db file for many different models is an inefficient way.

True, because there might be a ton of overlap between various similar models, but as far as I know, the only real way to completely save the state of the database is to commit a binary dump of the in-process database to file. Effectively, this is exactly what SAVE does.

One way to work around this is to save the state right before branching into one of your different models and then RESUME that before proceeding with additional preprocessing.

what should be the return value of pre_processing( )

Depends on the your approach when building your model. Depending on how you're doing this, you could potentially write out just the geometry as an Ansys neutral file (*anf) and then save that somewhere on your disk and return that location, or even potentially just write and immediately read in that file to memory and return that string. If you need just the mesh, you can always write it to disk as an archive file, and then read it in to a VTK object using the Archive class, and then either return that mesh, or save it to disk and return the location of that file.

---

I'd like to know what approach you take (if any of the above or one of your own), because it's an interesting problem. Often when building models for some sort of DOE (design of experiments), the model itself is only used to compute the solution and it's short lived and isn't cached. Caching the solution efficiently may be quite challenging depending on the type of the model and the approach you take to build it.

There's also the space-time tradeoff that you might be running into as well. Serialization of the database to disk is generally pretty quick as it's all in binary, but this can use a ton of disk space. One workaround is to append to Zip archives using Python; consider writing the database to disk, appending it to a zip archive, and then deleting the original copy. The binary databases tend to compress quite well, and several of them will likely have enough similarities that (depending on your compression algorithm), you'll be able to save substantial drive space at the cost of speed.

[kp3393]

Thanks, @akaszynski! for the solution suggested by you. I will definitely post my solution here. Perhaps I will document the final approach as an example script for adding to the PyAnsys documentation.