search

LLNL / ExaConstit

A crystal plasticity FEM code that runs on the GPU
BSD 3-Clause "New" or "Revised" License
46 stars 13 forks source link

Questions regarding the behaviour integration step #23

Closed thelfer closed 3 years ago

thelfer commented 3 years ago

Dear developpers of ExaConstit,

I am interested in your project for my own developments of a mechanical solver based on MFEM. @rcarson3 already answered several of my questions on MFEM and told me of the ExaConstit project as a source of inspiration. I must thank him for this suggestion as it illustrates nicely how to build the elementary inner forces and stiffness matrices.

However, I am always a bit lost when the behaviour integration is called.

If I am not mistaken, in ExaConstit, it is called in the SetUp method of the NonlinearMechOperator class which inherits from the NonlinearFrom class. This SetUp is called in the Mult method which is part of the NonlinearForm interface. The comments in the Mult function seems to state that this call is more or less unatural...

I have a few questions about this.

I would expect to integrate my behaviour in a class of the type NonlinearFormIntegrator, as this is done in the hyperlelastic examples in MFEM. In this case, I need to implement the AssembleElementVector (inner forces) and AssembleElementGrad (stiffness matrix) (Let alone partial assembly for the moment). But in this case, I don't know where to integrate the behaviour (unless I do some assumptions like AssembleElementVector is always call before AssembleElementGrad). It this the reason why NonlinearMechOperator inherits from NonlinearFrom ? If not, can I only implement a NonlinearFormIntegrator ?

Thanks for any help,

Regards,

Thomas

rcarson3 commented 3 years ago

Hi @thelfer in ExaConstit the constitutive model update is called within the Setup phase of our NonlinearMechOperator. The comment that I have in there about it being awkward is related to the fact that mfem::NonlinearForm::Setup currently does not have a version that takes in a vector argument. I honestly need to just update my fork/branch of mfem to change it, and I probably will the next time I update the entire fork and branch to the latest develop of mfem. Once, I've fixed that I'll move the Setup phase outside of the Mult call into another part of our newton-raphson class.

Now, we originally we did have the constitutive model update within our NonlinearFormIntegrator derived-class. However, once I started working on the partial and element assembly it became clear that would no longer be a truly viable option. Since, you would now have additional burden of more or less identical code across your various assembly methods. Therefore, I ripped it out and had it put into a Setup phase which doesn't depend on the assembly method.

It's really up to you where you want to do your constitutive model update. When you look at how NonlinearFormIntegrator is traditionally used it typically just calculates your gradient and vector terms. As I've mentioned above, you could do your constitutive update here. However, I found for my uses a more modular design was needed. So, I hosted it up out of the integrator and placed it within the NonlinearForm class which is already for responsible for calling the NonlinearFormIntegrator. Since the NonlinearForm already holds all of the necessary info you'll need within the integrator, I would say it is just as appropriate of a location to do this update.

Finally, our NonlinearMechOperator inherits from NonlinearFrom because it allowed us to override the default behavior of the NonlinearForm, and have it do what we needed it for our application where we were initially blazing new territory in the MFEM land of doing partial and element assembly methods for NonlinearForms. Since, those assembly methods had only been really supported within BilinearForms

thelfer commented 3 years ago

Hi @rcarson3,

Thank you for your insights. I am a bit slow to understand the rationale between the classes NonlinearForm and NonlinearFormIntegrator. If there were some kind of design documentation about this, that would be very helpful.

For what I understand of your comments, NonlinearFormIntegrator is not adapted for "our" needs and I shall better start studying the NonlinearForm class (and its overloaded version NonLinearMechOperator).

I really appreciate your comments about partial assembly. I must admit that this part was quite scary at first sight. Shall we expect some kind of backport of this work from ExaConstit to MFEM to alleviate the work on the user side ?

Thanks,

Thomas

rcarson3 commented 3 years ago

@thelfer you'll probably want to open an issue on the mfem repo about the NonlinearForm and NonlinearFormIntegrator design rational. I'm sure @tzanio and company will be able to provide a more detailed answer than I would.

Where it makes sense, I'm going to try and backport some of these integrators back into mfem. However, I can't really say what the time line for that might be other than I should have a PR put in sometime before end of 2021. Since, I would say this item is lower on my priority list for features that need to be completed over the next year. However, if enough users come forward requesting these integrators I can put a PR together after March.

thelfer commented 3 years ago

@rcarson3 Thanks again for your time. I'll open a new issue on the mfem repo as you suggested and reference this discussion.

rcarson3 commented 3 years ago

@thelfer I'm going to close this for now, but if you have any more questions related to how I've gotten a solid mechanics code working in MFEM feel free to open up another issue.

thelfer commented 3 years ago

@rcarson3 Thank you for you precious help. I shall have closed the issue myself.