Tags: llnl/ExaConstit
Tags
Version 0.9.0 - the one with multi-material support and the great ref… …actoring So, this version brought a major refactoring of the entire code base like seriously nothing was untouched... First, the option files has been completely revamped while the historical format is still supported and runs. Next, the output style is completely new and should make for easier post-processing / study of what occurred during the system as we've introduced logging and extended the post-processing aspect things quite a bit. Also, our light-up capabilities now support pretty much all of the major crystal symmetries. Now for the big changes, ExaConstit now supports multiple materials (we refer to them as regions) in the code. So, you can run multiple ExaCMech, UMATs, or some combination of the two together and have a sane manner in how they should interact with one another. This release is also the first one to heavily leverage LLM tools (Claude) to help code develop. While the LLMs weren't allowed to go wild they were heavily used to help develop new features and refactor things. See PR #60 for more info on my thoughts on this experiment. Documentation across the board should also be widly improved thanks to Claude pulling its weight and making my job easier. Code structure has also been greatly simplified in that we've moved over to a central SimulationState class which controls all of our main data, meshes, and primal variables and then is passed around which greatly simplifies our data ownership story. We also have a central class exclusively devoted to post-processing which also simplifies our story there as you no longer have to reach out to the mechanics_driver source file for that info. The ExaModel class was also greatly revamped by removing a ton of member functions and variables that weren't needed. A new multi-material ExaModel derived class now is the central class directly responsible for all of our material models and makes managing everything much simpler. The option parsing has also been greatly revamped and should make for adding new features and options easier in the future. Finally, the UMAT library loading aspect has been completely rewritten so users can provide us a shared library and the name of the function that we should be looking for, and it will do its best to find that function or one that matches standard UMAT function naming conventions. So yes a lot of code was changed in this release and was a major reworking of the code. Future releases should have less drastic changes and will likely be focused on refactoring smaller portions of the application or expanding the capabilities.
updating things so that we're compatible with v0.4.# of ExaCMech as t… …here were lots of breaking changes between v0.3.x and v0.4.x due to a large refactor. Breaking changes as part of this: We now require the RAJA Portability Suite for any GPU builds - go look at the scripts/installs for how to build those packages for either AMD or NVidia platforms The python executable needs to now be specified when building the test suite as something changed when I updated some cmake backends. So, cmake no longer just implicitly brings stuff in which is probably for the best... Updated minimum cmake version to 3.21 as we need something newer for HIP support but didn't want to go to far forward like 3.24 if people are stuck with something slightly older than that. We're now going to require c++17 going forward as there are lots of new features in there that makes my life easier from a coding point of view... Our version of MFEM has been updated as we needed new versions of RAJA and old MFEM versions were broken. I've marked which hashes of MFEM work with which release of ExaConstit to hopefully make life easy for folks. We no longer output the volumetric average plastic deformation rate tensor as this became too hard to support with newer models added to ExaCMech. So, I nixed it but you now have access to the volumetric average eulerian strain Material model names for exacmech are now considered legacy. I will continue supporting them going forward but for now on you can just reference all the short hand names for various models in this folder: https://github.com/LLNL/ExaCMech/tree/v0.4.1/src/ecmech/cases . See the options.toml for somewhat of a breakdown on this aspect of things. Fortran is no longer required. I guess while this is technically a breaking change I think it's an improvement... New features: Added the ability to specify a maximum time step for the auto time stepper feature. See the options.toml file for the name. Added a post-process light-up python script that under the hood uses Rust for all of the heavy lifting. This superscedes some of the work that Reilly Knox had added which was more or less pure python and required quite a bit more resources to use when trying to work with large datasets. Similar to the above, I added an insitu light-up script for users that does more or less what the python scripts do but all while the simulations are running. The runtime hit for something like this on the GPUs should be fairly minimal based on some testing I did when examing 4 HKL families. More HKL families might lead to a larger perf hit. We know support more crystal models thanks to the ECMech update and thanks to the new shortcut key :) The auto-time stepping feature is now more robust as we'll capture any failures from a code and update the time step based on that failure up to 4 times.
Version 0.7.0 adds several new features * Adds HIP support to the code and as part of this has a breaking change in that the rtmodel option CUDA has been removed and replaced with GPU to represent either HIP or CUDA runs * Added a number of workflows for users to leverage such as a material parameter optimization workflow and another that was leveraged to perform UQ studies for additive manufacturing materials * Added a set of new post-processing scripts that can be useful for performing lattice strain calculations similar to what you might obtain from a powder diffraction experiment
Version 0.6.0 of ExaConstit adds a number of exciting new features. 1. We've add support for outputting quantities typically used in light-up scripts used to simulate x-ray diffraction events. These quantities include the elastic strain, element centroid, and lattice orientation. See PR #42 for more info regarding this feature addition. 2. We added an automatic time stepping capability. This new feature allows one to not have to worry about coming up with a custom dt for each step of the simulation, or make use of the fixed delta time step. The automatic time stepping feature just requires an initial time step, a final time step, a minimum time step, and finally a time step scaling factor. The rest is left up to the code to get from the initial time step to the final. This feature can be quite useful when parameterizing new models. See PR #50 regarding the implementation of this feature. 3. We added a way to impose constant strain boundary conditions to a given boundary. This is accomplished by supplying a desired velocity gradient for a boundary from which the code figures out what the supplied velocity BCs should be for a given time step. Additionally, we allow one to mix and match constant strain and applied velocity BCs across all the boundaries. Lastly, users can also specify the origin that they would like the velocity gradient calculated which can allow for easy implementations of torsion-type simulations. Users can find more info about the implementation of this feature in PR #45
Fixes a minor/subtle bug that existed in all previous tagged versions… …. It's detailed in more detail in issue #32 Additional features added: A new script that takes in Neper gmsh outputted files and generate it into something that MFEM can read Additional volume averages/quantities can now be computed if the Visualizations.additional_avgs option is set to true. If this option is turned on then the volume average deformation gradient is computed. If an ExaCMech model is being run then additionally the plastic work is also computed and outputted.
PreviousNext