Move AssemblerLib parts to MathLib and ProcessLib#1166
Move AssemblerLib parts to MathLib and ProcessLib#1166endJunction merged 6 commits intoufz:masterfrom endJunction:MoveAsmLibParts
Conversation
| #include "BaseLib/ConfigTree.h" | ||
| #include "FileIO/VtkIO/VtuInterface.h" | ||
| #include "MeshGeoToolsLib/MeshNodeSearcher.h" | ||
| #include "MathLib/LinAlg/SparsityPattern.h" |
There was a problem hiding this comment.
Is that needed? You already have the compute header.
There was a problem hiding this comment.
Changed the include list using include-what-you-use tool.
|
⏩ As far as I can remember, you also wanted to
Maybe those changes will entail many small adjustments, so it's OK when you do them in separate PRs. But I find it always hard to see from your individual piece-by-piece PRs, how far your progress is and what you have planned to do until you have finished. So could you please open an issue with a (rather) complete list of what is left to do until the circular dependencies are resolved? |
|
As I have written in the description, there are no changes to the code in this PR. I shall create a list of problems regarding circular dependencies. |
|
I admit you cought me out not reading your introductory comment carefully enough 😄 (Although I can vaguely remember your "no code changes" phrase. Anyway, my critisism still holds. 😄 |
| #include "NumericsConfig.h" | ||
| #include "Parameter.h" | ||
| #include "ProcessVariable.h" | ||
| #include "vtkXMLWriter.h" |
There was a problem hiding this comment.
Did any compilation fail because we didn't have this long list? If not, I'd prefer to keep the list of includes short, because when changing some internals something in Priocess now we will always have to check, e.g., if #include <iterator> is still needed.
If you want to make something more consistent, I suggest adding the header issue to @norihiro-w's list (#1167) and make some cleanup-days, maybe end of may.
|
Second attempt for the includes: now absolute minimum strategy. |
|
|
||
| #ifndef PROCESSLIB_PROCESSUTIL_H | ||
| #define PROCESSLIB_PROCESSUTIL_H | ||
| #ifndef UTILS_CREATE_LOCAL_ASSEMBLERS_H_ |
There was a problem hiding this comment.
prefix PROCESSLIB_ ✅
|
Jenkins: OGS-6/Linux-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Linux-PRs/1725/ |
|
Jenkins: OGS-6/Mac-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Mac-PRs/1610/ |
|
Jenkins: OGS-6/Gui/Gui-Linux-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Gui-Linux-PRs/1694/ |
|
Jenkins: OGS-6/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Win-PRs/1602/ |
|
Jenkins: OGS-6/Gui/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Win-PRs/1580/ |
|
I had to rebase it, because the extrapolation test was not present. The last three commits do fix the extrapolation test. |
Updating includes and use some fwd.decls.
It is more related to the NumericsConfig than to the DOF table. Signed-off-by: Dmitri Naumov <github@naumov.de>
Creation of local assemblers belongs to the processes.
This slightly reduces included amount of code.
This is only used in local assembler implementation. Clarifies content of that file.
|
👍 |
|
👍 |
6 participants
GlobalSetupis used in ProcessLib/NumericsConfig.h; so it is moved to ProcessLib too.The previously ProcessUtils.h is split into two files for
createLocalAssemblersandinitShapeMatricesboth placed in ProcessLib/Utils/. I can imagine that ProcessLib/LocalAssemblerUtils would be a better directory name.No code changes, just includes and moves.