Hey,
I generated a cdb-File via Python and a cdb-File from the Journal-File I got from python. The two meshes distinguish drastically in the number of elements. The cdb-File created via Python has 5.6GB, the cdb-File created with the Journal-File has only 5.3MB
For python i used an anaconda environment with a Python 3.8 interpreter.
Do you have any idea why?
Best Regarts
Andreas
Can you post the journal file and the python script?
My first guess would be that sizing information did not get set in the journal file.
We don’t support ANSYS import. Could you save the files in Exodus and then import those files and look at the differences in the mesh?
Hey karl,
I tried, but I am not allowed to upload, because I am a new user.
The interesting part is, python generates the journal file, thus there shouldn’t be any difference.
I export the mesh into a cdb-File.
The key is there shouldn’t be a difference. Obviously, there is so the python file is doing something that is not being logged correctly in the journal file.
I am suggesting that you modify the export in the python file to do an "export mesh ‘myfile.g’ " instead of “export ansys cdb”. You can then do:
reset
import mesh geom “myfile.g”
and examine the differences in the mesh in the two files.
I will email you privately later today and you can email me the scripts. @gvernon Can you assist with the email?
ok, i will try.
my email is: andreas.gschwentner@tugraz.at
Hi Andreas,
I think part of the issue here is bad geometry. I am getting interference between the joch* volumes and the coils. You can see in the graphics where the volumes are overlapping. You are getting duplicate mesh entities in the overlapping volumes and this creates a problem.
I don’t know which material you want to keep in the overlapping areas. You can either do a boolean subtract or webcut the volumes. Either way make sure you delete the volume that is duplicated.
I believe the air is also duplicated after you do the boolean operation. Make sure you delete the old air volume before you save the new id in your id_dict.
Feel free to ask if you have more questions.
Hi Karl,
I think the problem has another background.
I executed the geo_magMat.py on our server and a colleague also tried the python-file. In both cases, everything works fine. We use the same trelis-version and the same anaconda-version. The only differences are the Linux-kernel:
With kernel:
5.4.0-62-generic (Server)
5.8.0-50-generic (Colleague)
everything works fine and the mesh looks fine.
With kernel:
I got the following message:
and the mesh show the problems described in the previous messages.
Best Regards
Andreas
Hi Andreas,
The QObject::startTimer message is being spawned when the license server starts up. That is not a problem. We are working on cleaning up that startup message.
What version of Cubit are you using?
I cannot guarantee the stability of the tetmesher when you are doubly meshing the volumes. You will also not create mesh that will be analysis suitable. So I go back to my geometry query. Are the materials in joch* and the coils the same? Can I just do a boolean unite on those?
That said, I have never validated the python script vs the journal file for creating the same number of elements. When I run your model, with the geometry errors, on my Windows machine and my Linux machine, I get different numbers of elements, but there are similar. I would expect repeatability. That is why I started looking at the number of elements.
| Python # elements | Journal # elements | |
|---|---|---|
| Windows | 28214 | 28123 |
| Linux | 28230 | 28074 |
I would like to get the geometry clean and then we can look at the python vs. journal file issue.
Hi Karl,
I am using Coreform Trelis Pro 17.0.
No, the joch and the coils have different materials.
Below, i uploaded a screenshot from Paraview.
I generated this mesh using the python-file I send you with Coreform Trelis Pro 17.0 on our server. As you can see, there are no geometry-issues.
The difference between my notebook and the server is the Linux-kernel.
Which linux-kernel you are using?
I’m running Fedora 31.
Kernel: Linux 5.8.18-100.fc31.x86_64
I overworked the python-script, every nodeset has the right surface and the ids are also correct . The script runs without any error, got a warning that an element has poor quality.
The resulting mesh is depicted below. If you have any idea why the element number distinguish so extreme, let me know.
Could you try saving in a different format, for example Exodus, and see if the file sizes are vastly different?
Do you see any difference in the number of elements if you import both versions into Paraview?
