Francois Hamon

Thanks for the quick reply and the clear explanation. Yes I confirm that I observe the same performance degradation without using the `__restrict__` keyword when I pass the references to...

If someone has a little bit of time in the next weeks, this (low-priority) PR is ready to be reviewed. It implements the option to choose between the $L^2$ and...

> @francoishamon I let you deal with it then? Hello @jhuang2601 and @TotoGaz yes, I am going to work on the rebaseline today

> I would use the case created by @cssherman in #2041 as an integratedTest. Sorry for the delay, I just added the test created by Chris to this PR, which...

If everyone is on board with the changes, this PR is ready to be merged.

> I personally prefer it this way. Isn't it also more consistent with what we do for the `stress` in general? Yes, with the previous formulation, stress had to be...

Thanks for taking care of that. My preferences go to the shortest options: - `namespace extrinsicMeshData` -> `namespace fields` - `getExtrinsicData` -> `getField` - `hasExtrinsicData` -> `hasField` - `EXTRINSIC_MESH_DATA_TRAIT` ->...

Maybe - `registerExtrinsicData` -> `registerField` for the function that takes one trait template - `registerExtrinsicData` -> `registerFields` for the function that takes multiple trait templates ?

Hello @cssherman There is a PR that fixes this issue: https://github.com/GEOSX/GEOSX/pull/1927 We have used it for our poromechanics field test cases with gravity, but I did not manage to merge...

Increasing the number of allowed components in the dispatch may/will have an impact on the compilation time, so we should be a little bit careful with this, I think (until...