[aspect-devel] inconsistency in use of x, y, and z

Timo Heister heister at clemson.edu
Wed Mar 11 05:41:45 PDT 2015


One additional feature I have been thinking about for a long time
would fix many of these issues:

If we had a way to introduce 'depth' as an additional variable that
can be used in all function expressions, most of those issues go away.

A second idea would be to introduce a preprocessor (similar to what
Jonathan does) so we can insert dimension dependent blobs in the
.prm's.

On Wed, Mar 11, 2015 at 7:13 AM, Wolfgang Bangerth <bangerth at tamu.edu> wrote:
>
> Magali,
>
>> In 2D the dimension of the box are set with X extent and Y extent.
>> However,
>> for the initial temperature
>> function, the variables that need to be used are x and z.
>
>
> As Timo pointed out, it's not that you need to use x,z. The default is in
> fact x,y, and that remains consistent then, but I recognize that that may
> not be what you want to use.
>
> I'm not sure what the best way to address this is. Whatever one does seems
> to rest on one or another frame of mind of what the "second" coordinate
> should be. The best I could think is to call the extents not
>   Set X extent = 42
>   Set Y extent = 108
> but something
>   Set Extent 1 =  42
>   Set Extent 2 =  108
> and then introduce another parameter
>   Set Extent order = XYZ    // or XZY
> which in 2d makes no difference at all and in 3d specifies whether the
> second extent is in Y or Z direction.
>
> We do like backward compatibility. I think I could somehow finagle this in a
> backward compatible way with some work. Or we could just make an attempt at
> documenting that in the box geometry, XYZ extents are unrelated to your
> choice of coordinates in function descriptions.
>
>
>> This is also an issue with the boundary indicators.  To easily move from a
>> 2D
>> to a 3D model, the boundary
>> indicators for left, right, bottom, top should remain 0-3 and adding the
>> third
>> dimension should add the boundary indicators 4 and 5 for the front and
>> back.
>>   I know you can get around this by using the words "front",  "back",
>> etc...
>> but this seems like a weird way of counting things
>
>
> That depends on your viewpoint :-) If you're fond of right handed coordinate
> systems (XYZ), then the existing order makes perfect sense. It comes from
> the order described here:
>   http://dealii.org/developer/doxygen/deal.II/structGeometryInfo.html
> If, on the other hand, you like left-handed coordinate systems (XZY), then
> what you suggest makes sense.
>
> Best
>  Wolfgang
>
> --
> ------------------------------------------------------------------------
> Wolfgang Bangerth               email:            bangerth at math.tamu.edu
>                                 www: http://www.math.tamu.edu/~bangerth/
>
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel



-- 
Timo Heister
http://www.math.clemson.edu/~heister/


More information about the Aspect-devel mailing list