Mesh objects from db files

[germa89]

Description of the feature

For the implementation of DPF in PyMAPDL, I have started by enhancing the PyMAPDL mesh object. I would like to use the DPF Mesh_region object as a complement of the dynamic methods we already have.

The issue is it seems I cannot create a mesh object from a DB file. I believe it has to be a DB file because I do not want to solve the model.
In MAPDL, when you save the format seems to be db always.

In addition, as discussed with @PProfizi, when you try to create a mesh object from a DB file the error is ... obscure.

>>> from ansys.dpf import core as dpf
>>> model = dpf.Model('model_ptyicsrvkq.db')
>>> model.metada.mesh  # Raise error
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "c:\users\gayuso\other_projects\pydpf-core\ansys\dpf\core\errors.py", line 136, in wrapper
    raise DPFServerException(details)
ansys.dpf.core.errors.DPFServerException: MeshProvider:9<-meshes_provider:10<-Operator(s) (mapdl::db::MeshProvider) does not exists in the registry !

model_ptyicsrvkq.txt

Attached the DB file as a TXT.

Steps for implementing the feature

I wish I knew...

Useful links and references

No response

[germa89]

By the way, exporting the model using SAVE, MODEL_NAME,RST does not solve it because still the file is encoded as DB.

[germa89]

Pinging @akaszynski @koubaa and @mikerife for visibility/advice on the MAPDL side. Do we have a way to generate an RST file without actually solving? (PSOLVE maybe?)

[koubaa]

@germa89 I don't consider generating a dpf mesh from a db file a critical need for dpf-based mesh in the short term.

It should be possible instead to generate a mesh from a live mapdl server prior to solving, using the mesh grpc interfaces. Getting a mesh from a db file could be a future goal.

[rlagha]

• @cbellot000, I think that having the mesh from the db is also needed for the load based workflow initiative

[mikerife]

Hi @germa89 I don't know of a way to generate an 'empty' result file. PSOLVE was undocumented at v14 so I'd not trust it anyway. Plus it could not do this. It was meant to continue a modal solve process if the FEA matrices existed (replaced by perturbation process) or create some FEA matrices without fully solving (and a few other things).

I've never heard of anyone wanting to create an empty (of results) rst file.

Not all db files contain FEMs.

@koubaa @germa89 can I ask what the 'pre' part of this statement on the DPF-Core page refers to: "It [DPF] is used to handle complex pre- or post-processing of simulation data within a simulation workflow." To me pre processing would necessitate accessing MAPDL db file. So I think I have the wrong understanding of pre processing used here.

Mike

[koubaa]

@mikerife I am not saying that it is unnecessary for dpf pre to handle db files. Clearly - that is an important need and goal.

I am saying that it is not critical in supporting this project on the pymapdl roadmap, for which "enhancing the PyMAPDL mesh object" (mentioned by German in the first comment here) is a necessary step. I apologize for the confusion.

[germa89]

Hi @koubaa

You are right, if I reuse the code already in PyMAPDL reader for parsing the model to VTK, I won't need DPF. My idea was to "externalize" this parsing to DPF since it is going to be the future post-processing library. This PR is for me to familiarize with this library.

Hi @mikerife ,

I've never heard of anyone wanting to create an empty (of results) rst file.

I would like a results file that has no results (empty) but still contains the FE model and such, so I can load the mesh from it. We should be able to use db files, but DPF at the moment does not support it.

[germa89]

You are right, if I reuse the code already in PyMAPDL reader for parsing the model to VTK, I won't need DPF. My idea was to "externalize" this parsing to DPF since it is going to be the future post-processing library. This PR is for me to familiarize with this library.

Thinking more about this. Creating the VTK requires quite a lot of code. I'm not sure how DPF is handling this, but in the Reader VTK elements are used, we have a dict that match each MAPDL element to a VTK shape. The thing is it takes some effort to develop this (not all the elements are implemented) and fixing the bugs (quite a few in the reader). If they are using something similar, I think we should pool everything together.