Add some constexpr values to the material declarations #1086
Conversation
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #1086 +/- ##
==========================================
- Coverage 13.80% 13.73% -0.07%
==========================================
Files 268 268
Lines 15007 15055 +48
==========================================
- Hits 2071 2068 -3
- Misses 12936 12987 +51 ☔ View full report in Codecov by Sentry. |
| @@ -30,6 +30,10 @@ format() { | |||
|
|
|||
| # NOTE: once the files of a directory are (almost) fully covered, consider moving it to allowlist_dir instead | |||
| local allowlist_file=" | |||
| src/Equations/elastic/Model/datastructures.hpp | |||
| src/Equations/viscoelastic2/Model/datastructures.hpp | |||
There was a problem hiding this comment.
What about viscoelastic(1)?
There was a problem hiding this comment.
Do we still support viscoelastic (1)? Otherwise, yes; I can change it.
There was a problem hiding this comment.
Wait—we don't have a Model/datastructures.hpp for viscoelastic (1). :)
There was a problem hiding this comment.
Yes, viscoelastic(1) is a prototype for a non-stiff pde with source term.
There was a problem hiding this comment.
We don't have a datastructure.hpp for viscoelastic(1), we just use the same as for viscoelastic2.
| def addStiffnessTensor(generator): | ||
| stiffnessTensor = Tensor('stiffnessTensor', (3, 3, 3, 3)) | ||
| direction = Tensor('direction', (3,)) | ||
| christoffel = Tensor('christoffel', (3,3)) | ||
|
|
||
| computeChristoffel = christoffel['ik'] <= stiffnessTensor['ijkl'] * direction['j'] * direction['l'] | ||
| generator.add('computeChristoffel', computeChristoffel) | ||
|
|
||
| def includeMatrices(matricesDir): | ||
| matrices = parseJSONMatrixFile('{}/sampling_directions.json'.format(matricesDir)) | ||
| return set([matrices.samplingDirections]) |
There was a problem hiding this comment.
This is anisotropy related, do we need it for all equations now?!
There was a problem hiding this comment.
It probably won't hurt too much to have it in... But I get it—I'll disable it if we don't have anisotropy enabled.
generated_code/generate.py
Outdated
| @@ -176,11 +180,50 @@ | |||
| except: | |||
| print('WARNING: ChainForge was not found. Falling back to GemmForge.') | |||
|
|
|||
| trueOutputDir = os.path.join(cmdLineArgs.outputDir, 'equation') | |||
There was a problem hiding this comment.
Why don't we use cmdLineArgs.equation here? This would pave the way for having more than one equation in the same binary?
There was a problem hiding this comment.
We could definitely do that. Originally, the equations were also templated, by SeisSol/yateto#62 (cf. what was done in #932; that's where most of this PR is from). It just doesn't completely work with the subroutine.cpp file yet.
There was a problem hiding this comment.
It's changed now to equation-{equation}-{order}-{precision}. The order part may be slightly overkill (as the matrices are usually pretty similar). But the equation partially and the precision surely would be necessary, I'd guess
| namespace='seissol', | ||
| gemm_cfg=gemmTools, | ||
| cost_estimator=cost_estimators, | ||
| include_tensors=include_tensors) | ||
|
|
||
| def generate_general(subfolders): | ||
| arch = useArchitectureIdentifiedBy('d' + cmdLineArgs.host_arch[1:]) |
There was a problem hiding this comment.
What about single precision here?
There was a problem hiding this comment.
That part was more meant to be precision-agnostic—i.e. the stiffness tensors etc.
(originally, it came from #932, to try to support multi-precision as well... Then forcing double was a good way to avoid templating in these classes as well)
There was a problem hiding this comment.
Makes sense. Can you add a comment that you use double here, since this kernel is not used at runtime?
There was a problem hiding this comment.
Done. In the same vein, couldn't we probably keep the anisotropy-related kernels (which are also only used during init); especially when going towards multi-material anyways?
| @@ -86,13 +86,13 @@ void seissol::kernels::DynamicRupture::setTimeStepWidth(double timestep) | |||
| { | |||
| #ifdef USE_DR_CELLAVERAGE | |||
| static_assert(false, "Cell average currently not supported"); | |||
| /*double subIntervalWidth = timestep / CONVERGENCE_ORDER; | |||
There was a problem hiding this comment.
Do we need this commented out code, still?
There was a problem hiding this comment.
I'd guess it's more or less an unfinished idea. If noone wants to continue it, I can remove it.
davschneller
force-pushed
the
davschneller/material-annotations
branch
from
c4ad306 to
5f2cf15
Compare
A refactoring PR.
We just add values, like e.g. the number of quantities to the material declaration (or quantity names)—so that we can mid-term replace all the external preprocessor definitions, yielding a (hopefully) cleaner and more equation-independent code.
Also, we namespace some structs and make some tensors precision-independent.