Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Post processing Updates #31

Open
rcarson3 opened this issue Feb 20, 2021 · 3 comments
Open

Post processing Updates #31

rcarson3 opened this issue Feb 20, 2021 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@rcarson3
Copy link
Member

The current post-processing stuff is a bit brittle and could be handled better. New models that don't fit the mold that's already within the code could easily break things.

The post-processing stuff really should be it's own class which holds all of the gridfunctions that we might want to use, and their respective FiniteElementSpaces kinda of like what's in the Axom::MfemSidreDataCollection for when they do reconstruction of stuff.

Although, it might also be worth thinking about whether or not we want this class to also be general enough to handle the restart functionality as well. I'm leaning towards keeping them separate just because that functionality could get more complicated if we decide to support restart capabilities through something other than Axom's sidre.

@rcarson3 rcarson3 added the enhancement New feature or request label Feb 20, 2021
@rcarson3 rcarson3 self-assigned this Feb 20, 2021
@rcarson3
Copy link
Member Author

During this update we'll want to also add the plastic work as an output. It shouldn't be too bad. So, we know once we have the flow strength which is defined within ExaCMech as:

flow strength = det(V^e)^(-1) * \Sum(\tau * gammadot) / (\sqrt(3/2 * D':D'))

where tau is our resolved shear stress (based on the Kirchoff stress), gammadot is our plastic shearing rate, D' is the deviatoric symmetric velocity gradient, and V^e is our elastic left stretch tensor (so det(V^e) is our relative elastic volume change). However, it should be noted that if det(V^e)^(-1) * \Sum(\tau * gammadot) is small ( < 1.0e-90) then the flow strength reverts back to the CRSS. So, we could do a simple check to see if our effective shearing rate is greater than the small value ( < 1.0e-90) and continue with the below other wise just set things to 0.0.

Therefore, our plastic work rate can be found by just multiplying our flow strength by \sqrt(3/2 * D':D'). Afterwards, our plastic work is simply the time integral of the plastic work rate.

@rcarson3
Copy link
Member Author

rcarson3 commented Apr 1, 2021

The plastic work was added in 638af65 but I still need to add the options to actually output the average plastic work in the body. Additionally, I'll be adding back in the ability to output the average deformation gradient of the body, which should make it very easy to then create what ever strain measure you want for plotting purposes.

@rcarson3
Copy link
Member Author

As I'm working on splitting the post-processing parts off, I'm realizing that we'll probably want a larger refactoring of everything...

Essentially, the mechanics driver has things a bit too intertwined. In other words, the parts that we might want in a post-processing class depends on a number of variables used elsewhere. I'll need to think this through, but one solution might be to adapt how serac (https://github.com/LLNL/serac) does things into our own code where they have a StateManager type class. Although, I would probably look into moving away from the static instantiation type thing initially. We could then pass a reference of this into the system driver, post-processing (const ref here), or a future restart type class (probably const ref here as well). The variables in this class would just be public to allow easy access to them. I'll work on this in a branch just to keep exaconstit-dev clean. Once, I'm happy with a solution I'll open a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant