Pushing the limit: 6 M volume elements mesh

About the development of the FEM module/workbench.

Moderator: bernd

User avatar
vejmarie
Posts: 713
Joined: Mon Jan 04, 2016 4:52 pm
Location: Somewhere between France, USA and Taiwan
Contact:

Pushing the limit: 6 M volume elements mesh

Post by vejmarie »

Ok, I am a little bit crazy, but I have been able to create a 12 Millions nodes and 6 Millions Volume elements mesh of my stair (8 steps). Things are moving on. That is the good news. The bad one is that my system crashed (still need to investigate why) and I had to reboot and discover one very painfull things, reading the input file is crazy crazy long ...

I don't know if you ever looked at a profile through Instruments on MacOS, but on a sample of 2.4M ms -> 2400s, I got 1 600s spent into FemFace::isFace which is a little bit crazy as tracking down the call stack it looks like this function is called while creating a mesh. It looks like that the reading process is creating new mesh at each new Volume elements which explain the crazy long time. This is done through:

FemGUI::ViewProviderFemMesh::onChanged
FemGUI::ViewProviderFEMMeshBuild::createMesh
FemFace::isSameFace

then bla bla bla ...

The remaining is in SMESHDS from OCCT which was things I was expecting. There might be perhaps a way to call onChanged at the end of the SMESHDS build up instead at each elements.

Any feedback on this ?

vejmarie

ps: 2400s is a sample, as my System is still reading the file after 2h and 21 minutes ...
User avatar
vejmarie
Posts: 713
Joined: Mon Jan 04, 2016 4:52 pm
Location: Somewhere between France, USA and Taiwan
Contact:

Re: Pushing the limit: 6 M volume elements mesh

Post by vejmarie »

Quick update 2:27 hours to read the file ;). So I generate my CalculiX input and check how to either:
- Disable FemViewProvider::onChange call while reading a file and just kick it off at the end of the read
- Do nothing in the function if a file is currently under read operation.

My expectation is that we could drop reading time by 60% which could be appreciated ;) and save my time at the coffee machine

vejmarie
User avatar
vejmarie
Posts: 713
Joined: Mon Jan 04, 2016 4:52 pm
Location: Somewhere between France, USA and Taiwan
Contact:

Re: Pushing the limit: 6 M volume elements mesh

Post by vejmarie »

Ok, the situation is more complex than I had expected, as the time consumed is really into the routine which is eliminating internal faces of meshes by sorting faces within ViewProviderFEMMeshBuilder::createMesh which is preparing the data for rendering by copying elements to the view provider. I will have a look later on to check if we could re-implement that differently with VTK and display the mesh shell in an easiest way, this might saves us time while reloading files.
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: Pushing the limit: 6 M volume elements mesh

Post by ickby »

vejmarie wrote:Ok, the situation is more complex than I had expected, as the time consumed is really into the routine which is eliminating internal faces of meshes by sorting faces within ViewProviderFEMMeshBuilder::createMesh which is preparing the data for rendering by copying elements to the view provider. I will have a look later on to check if we could re-implement that differently with VTK and display the mesh shell in an easiest way, this might saves us time while reloading files.
If it is displaying only I would not put overly much work into it. When using the new SMESH it makes sense to unite mesh and result view code and use the vtk approach for both, hence the current mesh viewprovider would be removed. This is of course not discussed or decided yet, but IMHO a very very likely thing to happen.
User avatar
vejmarie
Posts: 713
Joined: Mon Jan 04, 2016 4:52 pm
Location: Somewhere between France, USA and Taiwan
Contact:

Re: Pushing the limit: 6 M volume elements mesh

Post by vejmarie »

Hi @ickby,

Yes this is displaying. The issue I face is that I am using very huge meshes, and load time are crazy long mostly because the current viewprovider is copying data from SMDS Mesh structure to the viewprovider and looking for inner surfaces through a "hand" made algorithm. I believe there should be a way as to workaround this issue while waiting for a new VTK implementation of ViewProvider to determine through SMDS if a face is an inner one or outer one of the mesh, but didn't found it yet, instead of recomputing everything.

I am testing all of this stuff with new Salome version v7.

vejmarie
User avatar
vejmarie
Posts: 713
Joined: Mon Jan 04, 2016 4:52 pm
Location: Somewhere between France, USA and Taiwan
Contact:

Re: Pushing the limit: 6 M volume elements mesh

Post by vejmarie »

Anyway @icbky, any idea on when you VTK post treatment might be pushed in master ? I liked to test it in my branch, as to learn a little bit VTK, as I got new SMESH working ...
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: Pushing the limit: 6 M volume elements mesh

Post by ickby »

vejmarie wrote:Anyway @icbky, any idea on when you VTK post treatment might be pushed in master ? I liked to test it in my branch, as to learn a little bit VTK, as I got new SMESH working ...
I don't think a simple merge is a good idea anymore, if we go for the new SMESH the architecture should be totally revised. Than the result object should derive from MeshObject and only add data handling/processing, and the mesh viewprovider should use the VTK implementation. This is very much different to what I have created up to now. So my code can definitely be reused but must be restructured. I can definitely do this, but we never really decided how to go forward with the occ7 branch, and also did not yet discuss if making vtk a hard requirement for freecads App part is OK (after all it is a gui library which needs opengl to compile, this is normally not what we want in App as the command line tool should also work on non-gui servers).

So IMHO you should not go forward too much with this without bringing in the core devs and getting a decision if this very large change is ok. Only when clear that the roposed changes are coming it makes sense to implement features with them.
User avatar
vejmarie
Posts: 713
Joined: Mon Jan 04, 2016 4:52 pm
Location: Somewhere between France, USA and Taiwan
Contact:

Re: Pushing the limit: 6 M volume elements mesh

Post by vejmarie »

ickby wrote:
vejmarie wrote:Anyway @icbky, any idea on when you VTK post treatment might be pushed in master ? I liked to test it in my branch, as to learn a little bit VTK, as I got new SMESH working ...
I don't think a simple merge is a good idea anymore, if we go for the new SMESH the architecture should be totally revised. Than the result object should derive from MeshObject and only add data handling/processing, and the mesh viewprovider should use the VTK implementation. This is very much different to what I have created up to now. So my code can definitely be reused but must be restructured. I can definitely do this, but we never really decided how to go forward with the occ7 branch, and also did not yet discuss if making vtk a hard requirement for freecads App part is OK (after all it is a gui library which needs opengl to compile, this is normally not what we want in App as the command line tool should also work on non-gui servers).

So IMHO you should not go forward too much with this without bringing in the core devs and getting a decision if this very large change is ok. Only when clear that the roposed changes are coming it makes sense to implement features with them.
Hi Ickby,

Ok, let's wait to see if @bernd can recompile my branch on linux and if we can convince @sgrogan after to have a look if a Windows build could work. Then we will probably have to test the branch and see how stable it is (on my Mac at least it is really stable but it means nothing). I can ping the core dev but I do even not know who they are, and how to ? Even if new SMESH is VTK/OpenGL dependant I still believe that this is useful to move forward due to the new features we could develop on top of it and the benefit of relying of an external community to support some of our features. If we do not do that at the early stage of 0.17, we won't have time to run the adaptation of Fem WB to the new feature before release.

vejmarie
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: Pushing the limit: 6 M volume elements mesh

Post by ickby »

vejmarie wrote: I can ping the core dev but I do even not know who they are, and how to ?
Mostly wmayers and yoriks opinion is needed, jriegel is also a core dev but I've not seen him quite a while. Also we should give the package maintainers the chance to give their opinion, as occ7 in your branch means no backwards compatibility and that this package must be provided by package distributors (ubuntu, debian, suse, arch...)

For the vtk dependencie I also think wmayer is important, as the mesh workbench uses SMESH too and he is the author of it. Apart from that I think the FEM contributors can decide that for FEM themself, if they want that dependencie or not. In worst case FEM cannot be compiled on GUI-less systems without vtk.
Even if new SMESH is VTK/OpenGL dependant I still believe that this is useful to move forward due to the new features we could develop on top of it and the benefit of relying of an external community to support some of our features.
I'm with you, for FEM this would be a very huge improvement.
If we do not do that at the early stage of 0.17, we won't have time to run the adaptation of Fem WB to the new feature before release.
That is true, and another reason to do trigger this discussion.
User avatar
vejmarie
Posts: 713
Joined: Mon Jan 04, 2016 4:52 pm
Location: Somewhere between France, USA and Taiwan
Contact:

Re: Pushing the limit: 6 M volume elements mesh

Post by vejmarie »

ickby wrote:
vejmarie wrote: I can ping the core dev but I do even not know who they are, and how to ?
Mostly wmayers and yoriks opinion is needed, jriegel is also a core dev but I've not seen him quite a while. Also we should give the package maintainers the chance to give their opinion, as occ7 in your branch means no backwards compatibility and that this package must be provided by package distributors (ubuntu, debian, suse, arch...)

For the vtk dependencie I also think wmayer is important, as the mesh workbench uses SMESH too and he is the author of it. Apart from that I think the FEM contributors can decide that for FEM themself, if they want that dependencie or not. In worst case FEM cannot be compiled on GUI-less systems without vtk.
Even if new SMESH is VTK/OpenGL dependant I still believe that this is useful to move forward due to the new features we could develop on top of it and the benefit of relying of an external community to support some of our features.
I'm with you, for FEM this would be a very huge improvement.
If we do not do that at the early stage of 0.17, we won't have time to run the adaptation of Fem WB to the new feature before release.
That is true, and another reason to do trigger this discussion.
I shouldn't say that and even don't know if it might be good idea, but there should be a way to include the "patches" for OCCT7 through CPP pragma by identifying the OCCT version at compile time which could keep 0.17 compatible with older OCCT release in the case one of the distro are still far behind it. I didn't made it this way for 2 reasons;
- I wanted to give a try and see if it could work
- When I started to make it, some files were getting really ugly.

Ok, let's put some "pressure" on @bernd and see if he can compile it on linux. I do also have a friend which started this. Then we can re-pop the discussion to the developper, do you believe FEM forum is the right place or should I go to developer (I will need supporters ;))

Regarding Mesh workbench, I have tested it with new OCCT and it worked (following a few patches), so I tried to keep the same level of functionalitlies.

I agree in the case of headless we shall probably disable FEM, as this is "mostly" a pre/post treatment tool of a 3D model, so there is no way to apply boundaries conditions and it will be hard to do that "by hand" (I made it in the 90's and this was a total nightmare to edit an Abaqus input file)

I am supposed to meet with the Salome guys next week (our office is 200 m from there). They are discovering FreeCAD just as a quick info.
Post Reply