NEML integration #60
NEML integration #60
Conversation
…ansionEigenstrainNEML. Test check uniaxial stress behavior for simple problems.
Add NEML as a submodule Add Makefile to build NEML using the MOOSE build system Fix issues with NEML tests and make them run only if NEML is compiled in
| @@ -0,0 +1,37 @@ | |||
| #ifndef COMPUTETHERMALEXPANSIONEIGENSTRAINNEML_H | |||
| #define COMPUTETHERMALEXPANSIONEIGENSTRAINNEML_H | |||
|
@reverenedbedford FYI, I took the commit from your PR and built onto it in this PR. Once we get this all sorted out, we'll just want to close your original PR. I talked this over with @dschwen, and I think we'll make a change to ComputeStressBase in MOOSE to make it so that it doesn't require an elasticity tensor. Once we get that change pushed through, I'll go back and remove that stuff from the NEML stress calculator. |
bwspenc
force-pushed
the
neml
branch
3 times, most recently
from
fdb3692 to
52b3126
Compare
|
Job Precheck on 52b3126 wanted to post the following: Your code requires style changes. A patch was auto generated and copied here
Alternatively, with your repository up to date and in the top level of your repository:
|
bwspenc
force-pushed
the
neml
branch
3 times, most recently
from
48e6aca to
0d3e81e
Compare
Also: Add requirements to tests Add documentation for NEML objects Update neml submodule -- this version compiles with the MOOSE build system Ignore build files in NEML Add headers to NEML interface source files Fix miscellaneous Makefile issues
On Linux, something about including the libxml++ headers and their dependencies didn't play nicely with the make_unique macro in libmesh. To get around this, only include those files when building the neml source, and not other MOOSE source files.
|
@reverendbedford I'm having a heck of a time getting this to compile on all of our platforms due to the libxml dependency. It compiles and runs fine on my mac in opt and debug mode. I got the libxml++ dev package installed on the linux box that we do our testing on, and I thought I had it working, but now it's failing because of these undefined references to libxml++ functions (only on debug -- opt works fine): Linking Executable /opt/civet/build_0/blackbear/blackbear-dbg... I've got an idea to get around these issues with libxml++. We're already dependent on the boost library, and that is one of the libraries that we have good support for in our packages. It looks like the boost property_tree can parse xml. If we could swap libxml++ for that, that would make it a lot easier to support neml with our regular packages. I'm going to attempt to modify neml to use property_tree. If you have any objections to that before I go too far down that path, let me know. |
|
I have no objection at all. In fact if it works I would appreciate a pull request onto NEML proper, as I would really like to eliminate all the libxml++ dependencies. They make compiling on windows even more of a pain than it normally is. The issue with libxml is likely due to an API change they made awhile ago. I have compiler macros that are supposed to switch between the different APIs (there were not many changes) but it could be I missed something (like that form of get_children?) |
|
OK, good to know. If we get it working, we'll definitely submit a pull request to NEML. We will have NEML be a submodule to BlackBear, so that we would always be pointing to the main repository, and periodically update the version of NEML after we verify that the new versions still pass our tests. |
|
@dschwen At long last, I finally have this passing! We got rid of the libxml++ dependency. If you could please take another look at this, that would be great. |
|
FYI @reverendbedford I think this is ready to go. |
| @@ -0,0 +1,4 @@ | |||
| [submodule "contrib/neml"] | |||
| path = contrib/neml | |||
| url = ../../Argonne-National-Laboratory/neml.git | |||
There was a problem hiding this comment.
Shouldn't this be a remote URL? This looks like you added a local repo as a submodule.
There was a problem hiding this comment.
Doing it this way gets it through either ssh or https, using whatever protocol you used to clone the repository. I think this is how we grab the libmesh submodule in moose.
There was a problem hiding this comment.
It works because they’re both hosted on GitHub.
There was a problem hiding this comment.
Oh, cool. I guess I learned something new: Submodule urls can be relative to the superproject’s default remote repository (the remote of the remote-tracking branch of the current branch!)
ref #59