min refinement function may crash on input files

[geodynamics]

min refinement function may crash on input files

[gassmoeller]

Yes that is a flaw in the current implementation. The main reason for using this default is that we tried to stay compatible to input files using the old minimum refinement function. However I think it is more important to have working default values, so maybe we should just change the default "Coordinate system" to "cartesian". I did not quite get your suggestion (a typo?), but I think we always have to declare the 3-dimensional parameters, since in declare_parameters we do not know, whether we need them later on.

[bangerth]

Yes, a typo. I meant to say "which would require doing
Functions::ParsedFunction::declare_parameters (prm, 1);
instead of
Functions::ParsedFunction::declare_parameters (prm, dim);"

Your suggestion would be one way. But I think there's a fundamental flaw that for one of the two choices of coordinate system, one will always have to also describe the name of the variables.

What would you think of splitting the class instead? If the default is to use a 1d, depth dependent function for historical reasons, then maybe we should have a different class called, say, MinRefinementFunctionCartesian or similar that simply always works in a dim-dependent coordinate system. I think the way it's currently done is always going to lead to confusion.

[gassmoeller]

I am not generally opposing the idea of splitting the plugins. However I am a bit worried that we might provide to many options/files for the user, which are too similar in functionality. Would you be fine with the workaround in #177? We could simply always use the function with dim input variables and in the case the user only wants to use depth ignore the other components. This would need to be mentioned in the documentation of course.

[bangerth]

Yes, I think your concern is well taken.

I suppose that could work. We would then document essentially something like the following (or did you have something else in mind?):

"Whatever the coordinate system chosen, the function you provide in the input file will depend on variables 'x', 'y' and 'z' (if in 3d). However, the meaning of these symbols depends on the coordinate system. In the Cartesian coordinate system, they simply refer to their natural meaning. If you have selected 'depth' for the coordinate system, then 'x' refers to the depth variable and 'y' and 'z' will simply always be zero. If you have selected a spherical coordinate system, then 'x' will refer to the radial distance of the point to the origin, 'y' to the ... and 'z' to the ..."

[gassmoeller]

I updated #177. Do you think that is the way to go? It has the drawback that old parameter files using
"Set Variable names = depth"
need to be updated to something like
"Set Variable names = depth,y,z"
I explained that in the updated test file.

[bangerth]

Fixed with #177.