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

[Jonathan Perry-Houts]

I like the depth variable idea!

For whatever it's worth, one cool thing about the preprocessor trick is
that I can do things like implement a whole suite of models in one .prm,
and run each instance by just changing a flag. It avoids errors
introduced by maintaining a whole set of .prm files that are very similar.

That said, I don't know that building a preprocessor in to Aspect would
be more useful than just doing it through gcc. One thing that would make
it easier would to allow Aspect to accept .prm files from stdin rather
than a file. Maybe I'll do that, now that I think about it.

On 03/11/2015 05:41 AM, Timo Heister wrote:
> 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
> 
> 
> 

-- 
Jonathan Perry-Houts
Ph.D. Candidate
Department of Geological Sciences
1272 University of Oregon
Eugene, OR 97403-1272

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <http://lists.geodynamics.org/pipermail/aspect-devel/attachments/20150311/ac24970f/attachment.sig>