The Great Refactoring + Multi-Material support #60
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Small cmake install fix
Fixes a BC manager edge case that was addressed in other areas
Had Claude help me with the post-processing driver aspect of things as it also helped with all of the trait stuff. No way this stuff probably works right now but it at least starts getting us moving in the right direction...
Claude helped me fill out some of the impl details for the qspace / qfunc work but largely I had to iterate on its initial design as it was making some assumptions that weren't great
Had to add a time management class to keep all the logic related to that in just one class Updated the partial quadrature space just a bit for the case when the incoming index is empty to signal all values are provided Initial complete implementation of the simulation class. I also added a bunch of other stuff here from the initial prototype of it based on common things that we'd generally across all of the simulation stuff.
Iterated with Claude a bit on a potentially new option parser for ExaConstit which will hopefully be more flexible for multi-material systems. Additionally, I've started to revamp things a bit so that at least all of the files outside of the mesh should be read ahead of time so we can avoid more of MFEM's file load options as they generally aren't the best. I'm still not the most satisified with how things are broken up for everything, but I do believe it's moving in the right direction.
…atures and update SimState while at it Added quite a bit more validation aspects to the refactored options parser. Although, I still need to test this and also create better logging features. Updated a number of the options structs based on some of the original info not making sense or just needing to make somethings optional and such. Started to update the SimulationState class to make work with this newly refactored ExaOptions class. Additionally, I added in the necessary logic to handle the grains2region mapping even if the grains2region mapping was not provided by users. Things are still very much a work in progress though but the current state is getting us much closer to where we want to be in-order to handle multi-material systems.
…build yet) Starting to incrementally move everything over to these new header files. I'm still fixing compiler issues in the simulation_state.* files. So, it's coming along but I still have more to go. Outside of that, I've got a ton of stuff now compiling and fixed quite a few bugs with the new classes being added. So, everything up to the SimulationState in terms of the compilation stage of things now at least compiles. Although, I threw my hands up in the air for some of the features that no longer exist in the option file such as if the vgrad_origin is being used or if we're using the experimental mono_dirichlet BCs... I'll work through all of that later but hey it's a start.
The SimulationState class now compiles after fixing numerous issues. Also made some changes to the ExaOptions class and related sub-classes to make things a bit more sensible.
Fixed a ton of the compile errors but still got to do all of the time step management type stuff Pushing off the post-processing stuff for a bit longer as it's currently not critical to get done...
New changes all now compile and we can now at least get something produced but things crash hard when we try to run things :/ So, we get to debug things a bit more to see if we can get things working in the new code paths.
Ran into a number of interesting issues that took a bit of working out the root issues... Thank you ASAN for rooting out the issues.
Went ahead and had Claude generate outputs of all of the simulation file options that we are using and to try and make it somewhat similar to what was in the original version of things. Next, a few small bug fixes related to the options were also brought in here to get the simulations to actually run
The voce_full / ea / pa runs are now running and returning answers that are identical to the original v0.8.2 release of the code. Although, it should be noted that I still need to work through some more options issues with the averaging issues not working quite as expected. However, we're doing pretty good so far. This included quite a few small bug fixes to get this working
Fixed issues related to the vgrad BCs and also the automatic time stepping BCs Fixed an issue if the auto time stepping was present in the option file but the custom one was also provided Updated some of the driver print options so that it always tells us what cycle we were on and the various time info aka the current time, prev dt, new dt, and factor things changed by for everything
Replaced the FESpace and ExaOptions use cases with the SimulationState in SystemDriver and the NonlinearMechOperator Next step will be to replace more in the ExaModel classes
…fixes We now leverage the simulation state class for all of our primal and mesh related quantities of interest rather than passing things down the call stack / having classes that have no business controlling things moving the mesh around... Fixed a few bugs in the process for the TimeManagement related to when we only have 1 time step. Fixed an issue with how the SimulationState was assuming the Update step should occur after we've completed a step which led to some differences in our results with the legacy code. Fixed an issue with how our mesh nodes were being connected with the current nodal values as some of MFEM's funcs operated internally differently than I expected them to... Currently the basic UMAT related tests are turned off as they're broken... I'll have to work something out though for those.
…rial state Temporarily disabled the whole post-processing stuff but stuff are running with right results it seems...
Added a new "super" model class which runs all of the material model aspects of things. Theoretically, this should now be able to run multi-materials but have not tested it at all...
…aterials For ECMech and UMat models made sure the model setup aspect of things Additionally added some helper functions to the partialQuadSpace to make things a bit easier to work with Had to update some of the kernel logic also to make things a bit simpler Also Claude helped with some of this refactoring
Thanks to Claude I didn't have to completely rewrite the state variable initialization aspect of things. So, it does appear that the multi-material stuff is now working :) I need to still do some reworking of some stuff and add a new test related to the multi-material stuff but hey things are looking good now.
…her small changes Used Claude to help refactor the state variable initialization aspect so that the orientation stuff is all handled in different functions. It generated most things which appear to be working. However, it also attempted to generate conversion funcs for going from unit quats to bunge euler angles or rotation matrices. However, I did not like it's approach so I replaced it them with implementation that I know are numerically stable and work as I would expect. Outside of that removed the numStateVar input condition in the SystemOperator class and NonlinearMechanicalOperator (NLMO) class. Also removed the mech_type variable in the NLMO class.
… least fcn capitalization For anything that is not IO related (anything but src/options and src/utilities/unified_logger.*) all the function signatures have been converted to "PascalCase" in-order to be consistent with how MFEM does things and just standardize things. IO related files (src/options/* and src/utilities/unified_logger.*) all of the functions were set to "snake_case" as this was cleaner looking for the options work and then for the loggers it better matched what the STDLIB is doing which makes things easier to read / reason about. I honestly would prefer all functions signatures look like this but with how MFEM does things that just clashed too much everywhere else :( Now there were also some member variable name changes any member variable that ended with the postfix "_" had that postfix removed. This addition is something that Claude just loves to add... and I finally got a round to removing them. I still need to make the member variable names consistent everywhere but that will likely be a fight for another day... Note, I did try using clang-tidy to enforce this automatically but it kept getting too many things wrong or changing too much. So, I just abandonded that idea of using it as a tool to automatically do this for us. I might still look into using it for other things though as well as leveraging like clang-format.
…GenerateGradBarMatrix as it was prev wrong
rcarson3
changed the title
Member
Author
|
HIP GPU builds now appear to be running for a number of different test cases |
Tired of having small differences in the build scripts across everything so had Claude help generate a unified set of build scripts based on a new refactored build script I also had generated from another LLM. Now pretty much everything is shared between them and we just have some simple config files created for new systems and very simple install scripts that look similar between all systems.
…ided build scripts Claude helped generate documentation for all of the build scripts and how to use them. The documentation is pretty extensive which is why we now have a doc directory. Hopefully the new documentation makes it easier for people to get started / have something they can work more towards with their own build systems.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR essentially complete reworks almost every part of ExaConstit. So, it's a major breaking change. I'll add a lot more comments about everything that's changed later but for now the below are some basics things that changed.
So ExaConstit had slowly started accumulating a lot of technical debt over the years and it was becoming harder to support new large features such as multi-material support.
So, I pretty much have re-written most everything from having a central class that contains all of the main simulation data that is passed around to everything that needs it. To completely re-writing the post-processing and option files to finally adding in multi-material support.
One major breaking change externally is how the post-processing stuff is handled now. So, the volume average / volume integration files now contain a header line and also contain 2 new columns that contain the simulation time and the current simulation volume. Additionally, we save all of these files into a folder that's based on the basename provided in the simulation along with a few other things. Additionally, we specify whether these files pertain to a region or if they are global values.
Visualizations have also had some major changes as well in that they now go to a specific folder called visualizations and we now have sub-fields for both region and global states. I expect this to be an area that sees a lot of improvement though as things could be a bit more efficient.
One last thing to note, I did leverage Anthropic's Claude to generate aspects of this PR such as the options and post-processing scripts. I usually specified in a commit if Claude helped. This was more of an experiment to see how helpful such tools could be when performing a major refactor to see if they expedite things. I would say to a degree they can help, but I found if I gave the tools too much freedom they seemed to produce overly-complicated designs that I really didn't like. However, if I constrained it to only do a few things and provided it a template for what I wanted done then it was a pretty useful tool. So, it was a mixed bag but ultimately it has been a useful tool for such a large refactoring and I'll likely continue to leverage it for things that it makes sense to have it help out with.
Fixes #39 and fixes #31