moose
moose copied to clipboard
TimedSubdomainModifier
To ease re-assignment of all elements belonging to one subdomain to another subdomain during a run, make Moose input files shorter, and reduce potential sources of error I'd like to propose the TimedSubdomainModifier
.
includes:
- TimedSubdomainModifier
- TimedElementSubdomainModifier
- DelimitedFileReaderOfString (modified copy of DelimitedFileReader)
refs #26952
DelimitedFileReaderOfString (modified copy of DelimitedFileReader)
this is going to be troublesome. What made you do that? What's the missing feature in DFR?
DelimitedFileReaderOfString (modified copy of DelimitedFileReader)
this is going to be troublesome. What made you do that? What's the missing feature in DFR?
As far I understood DelimitedFileReader, it always converts all values to double. To ease model definition and debugging I'd like to allow subdomain names (e.g. "Box1"). Is there a way to do so with DelimitedFileReader?
Subdomain names are definitely a good idea. Maybe we can adapt the DFR. I ll take a look. I have to get some papers out of the door so wont be till next week
I'd rather have a templated interface to DFR that does a type conversion on the fly.
I'd rather have a templated interface to DFR that does a type conversion on the fly.
Could you please explain more in detail?
I'd rather have a templated interface to DFR that does a type conversion on the fly.
Could you please explain more in detail?
Add a templated getData
method to the original DelimitedFileReader
that either returns a copy of a column vector converted into the desired type, or returns an iterable proxy object that can be used in place of a vector (but that might be over engineered :-))
Either way, the copy paste modification of DFR has approximately 0% chance of passing a review.
Add a templated getData method to the original DelimitedFileReader that either returns a copy of a column vector converted into the desired type, or returns an iterable proxy object that can be used in place of a vector (but that might be over engineered :-))
Either way, the copy paste modification of DFR has approximately 0% chance of passing a review.
I fully agree that the copy of the DFR is no option. Unfortunatley, the modifications to the existing DFR in the form recommented by you and my c++ skills are no match. From my point of view there are the following options:
- I remove all code related to the CSV data source (and therefore also the DFR) from this pull request. If the DFR receives an update from a capable contributor, we can add the CSV functionality to the TimedSubdomainModifier with a later PR.
- We are postponing this PR until the CSV is hopefully updated at some point in the future.
Hello
Let's hold the PR for now. I ll get to it once I'm done with my current project If you need the capability, you should be able to rebase the branch every time you need to update MOOSE. You may even find improvements while using it
@grunerjmeier I added the template and made small changes to the code. note that I squashed to remove the readerofString source file from history
Can you please add:
- a documentation page for each of the two objects in framework/doc/content/source/userobjects
- a test for test for each object and method. So probably 3 regression tests. The simpler the better
to finish the PR. Once there are tests I'll check if it behaves as expected then we can merge
given that there is no test right now it's not impossible I broke one of the two objects with my changes happy to fix it as long as you add a single test
given that there is no test right now it's not impossible I broke one of the two objects with my changes happy to fix it as long as you add a single test
Dear @GiudGiud,
while preparing the tests I run into an problem related to the DelimitedFileReaderTempl
when compiling the tests (cd ~/projects/moose/test --> make -j 32). Please see below. Do you know how I can resolve this?
/home/mjg/mambaforge3/envs/moose/bin/../lib/gcc/x86_64-conda-linux-gnu/10.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: /home/mjg/projects/moose/framework/libmoose-opt.so: undefined reference to `MooseUtils::DelimitedFileReaderTempl<double>::DelimitedFileReaderTempl(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, libMesh::Parallel::Communicator const*)'
/home/mjg/mambaforge3/envs/moose/bin/../lib/gcc/x86_64-conda-linux-gnu/10.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: /home/mjg/projects/moose/framework/libmoose-opt.so: undefined reference to `MooseUtils::DelimitedFileReaderTempl<double>::getNames[abi:cxx11]() const'
/home/mjg/mambaforge3/envs/moose/bin/../lib/gcc/x86_64-conda-linux-gnu/10.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: /home/mjg/projects/moose/framework/libmoose-opt.so: undefined reference to `MooseUtils::DelimitedFileReaderTempl<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::DelimitedFileReaderTempl(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, libMesh::Parallel::Communicator const*)'
/home/mjg/mambaforge3/envs/moose/bin/../lib/gcc/x86_64-conda-linux-gnu/10.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: /home/mjg/projects/moose/framework/libmoose-opt.so: undefined reference to `MooseUtils::DelimitedFileReaderTempl<double>::getData(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const'
/home/mjg/mambaforge3/envs/moose/bin/../lib/gcc/x86_64-conda-linux-gnu/10.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: /home/mjg/projects/moose/framework/libmoose-opt.so: undefined reference to `MooseUtils::DelimitedFileReaderTempl<double>::getData() const'
/home/mjg/mambaforge3/envs/moose/bin/../lib/gcc/x86_64-conda-linux-gnu/10.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: /home/mjg/projects/moose/framework/libmoose-opt.so: undefined reference to `MooseUtils::DelimitedFileReaderTempl<double>::getData(unsigned long) const'
/home/mjg/mambaforge3/envs/moose/bin/../lib/gcc/x86_64-conda-linux-gnu/10.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: /home/mjg/projects/moose/framework/libmoose-opt.so: undefined reference to `MooseUtils::DelimitedFileReaderTempl<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::getData() const'
/home/mjg/mambaforge3/envs/moose/bin/../lib/gcc/x86_64-conda-linux-gnu/10.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: /home/mjg/projects/moose/framework/libmoose-opt.so: undefined reference to `MooseUtils::DelimitedFileReaderTempl<double>::read()'
/home/mjg/mambaforge3/envs/moose/bin/../lib/gcc/x86_64-conda-linux-gnu/10.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: /home/mjg/projects/moose/framework/libmoose-opt.so: undefined reference to `MooseUtils::DelimitedFileReaderTempl<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::getNames() const'
/home/mjg/mambaforge3/envs/moose/bin/../lib/gcc/x86_64-conda-linux-gnu/10.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: /home/mjg/projects/moose/framework/libmoose-opt.so: undefined reference to `MooseUtils::DelimitedFileReaderTempl<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::read()'
collect2: error: ld returned 1 exit status
make: *** [/home/mjg/projects/moose/framework/app.mk:457: /home/mjg/projects/moose/test/moose_test-opt] Error 1
I would clean the repo (after git commit for everything) then rebuild
just checked, builds fine for me as long as remove the old header I forgot to remove in TimedSubdomainModifier
Dear @GiudGiud,
After many attempts I'm unable to get the build process to succeed. The error message remains unchanged.
I tried:
- I updated my development machine (Ubuntu in WSL): clean of repo, mamba update --all, conda update moose-dev, ...
- When I switch to the "next"-branch in my moose-clone (NOT having the new DelimitedFileReader) it compiles without problems: my copy of the (now outdated) next-branch
- I created a new branch from my "next"-branch as a sister-branch to TimedSubdomainModifier and copied only the C and H-file of the DelimitedFileReader. When compiling, I get the error messages as above.
- On a new PC, I newly installed WSL, Ubuntu, Moose from scratch. My TimedSubdomainModifier does NOT compile there either.
- I asked a colleague with more C++ knowledge than me. We spend some time checking the code, but we did not solve the problem.
Any hints I can pursuit next week?
I ll pull your commits today and try it. I built my branch yesterday, I did not see you added commits yesterday.
@grunerjmeier do you have those test inputs? You could create them with your initial version of the PR btw
Dear @GiudGiud,
do you have those test inputs?
Only as a first untested draft. The idea was to finalize them and to test your modifications using the final code from you.
You could create them with your initial version of the PR btw
Yes, I will do that next week. I'll be out of office till than.
your branch compiles fine on my machine. Could you try to see if it compiles with
cd ~/projects/moose
git commit -am "Everything saved"
git clean -xfd
cd test
make -j6
your branch compiles fine on my machine. Could you try to see if it compiles with
cd ~/projects/moose git commit -am "Everything saved" git clean -xfd cd test make -j6
I used exactly the commands given by you. Unfortunately, this does not help.
Dear @GiudGiud
Finally, I can provide tests and a docu.
@grunerjmeier do you have those test inputs? You could create them with your initial version of the PR btw
I followed your recommendation and created the tests and docu using my "old" DelimitedFileOfStringReader
.
Please note, I did two commits:
Job Precheck on 9c71d81 wanted to post the following:
Your code requires style changes.
A patch was auto generated and copied here
You can directly apply the patch by running, in the top level of your repository:
curl -s https://mooseframework.inl.gov/docs/PRs/27092/clang_format/style.patch | git apply -v
Alternatively, with your repository up to date and in the top level of your repository:
git clang-format d76ac1a60ff0e4298f84fe8331f05c55d9948632
Dear @GiudGiud,
With 4e9ccfa I switched back to the new implementation of the DelimitedFileReader
. As before, with the new DelimitedFileReader
I'm unable to build ("undefined reference to 'MooseUtils::DelimitedFileReaderTempl<...>'" ). With the old DelimitedFileReader
just one commit before (b0a476d) the build and tests succeed.
With this situation, please consider 4e9ccfa.
Thanks for creating the tests! I ll finish this up either this week or early next week. Then I ll be away for a bit
I ll probably squash these commits, we dont really want the back & forth in the commit history
Ok the template should work now on your machine. I was missing a few things. Funny that it still compiled on my machine.
Could you please check in the csv file for the subdomain modifier test? You need to git add -f for csv files as they are in the .gitignore file
Ok the template should work now on your machine. I was missing a few things. Funny that it still compiled on my machine.
This looks good. I can confirm that with your changes it now compiles on my machine.
Could you please check in the csv file for the subdomain modifier test? You need to git add -f for csv files as they are in the .gitignore file
Please find the missing file now commited as well (6089d80).
ok good.
I removed the merge commit then worked on making the test lighter. Using less files, less variables and 1st order elements. It's quite small now so all good. However I am not seeing the subdomain changing? Even with the initial gold files (see 6089d80 ) it seems the subdomains are not changing between the start exodus and the final one (s006) one?
Dear @GiudGiud
First, thanks for making the tests lighter.
However I am not seeing the subdomain changing?
The gif below is derived from the gold file of the lighter csv-test using paraview (tsm-direct looks the same). The color coding is "vtkBlockColors". In the gif, the middle block changes (at t = 0.4) from red to green and back to red (at t=0.6). Up until now I wrorked under the assumption, that that means, that these elements "had changed blocks". So yes, the last timestep looks like the first. But in the intermediate timesteps some elements get re-assigned. The idea was to test more than one subdomain transitions.
ah ok I should have paid closer attention. i ll change the test again and it should be good after an independent review
Job Documentation on 40e3902 wanted to post the following:
View the site here
This comment will be updated on new commits.
Dear @hugary1995, Thank you very much for your review and comments. I was able to solve some points directly. However, I still need your input on other points. Please see above.