[aspect-devel] Material models with 3-D ASCII input

[Rene Gassmoeller]

Hi Marie,

let me answer to your first mail, because it still contains all of your
original text.


On 01/31/2018 04:10 AM, Marie Kajan wrote:
>
> Hi all,
>
>
> I have an ASCII data file containing viscosity values with
> corresponding spherical coordinates. I've used the
> Utilities::AsciiDataInitial class in the past to implement an initial
> temperature field in 3-D, and now I would like to implement viscosity
> in a similar way. Existing material models seem to mainly use the
> Utilities::AsciiDataProfile class, which can only implement 1-D
> parameters. I'm not sure that Utilities::AsciiDataLookup is what I
> want either.
>
>
AsciiDataLookup might be what you are looking for, but let me explain
this further down.

> I tried to write a material model that incorporated ASCII data in a
> similar fashion to the 'AsciiData' initial temperature model. My code
> simply declared Utilities::AsciiDataInitial as an additional public
> member in the main class of my material model like this:
>
>
> template <int dim>
>
> class XXXXX: public MaterialModel::Interface<dim>, public
> ::aspect::SimulatorAccess<dim>, public Utilities::AsciiDataInitial<dim>
>
>
> but it turns out that Utilities::AsciiDataInitial already inherits
> from the SimulatorAccess class, so this coding attempt gave me errors
> about SimulatorAccess functions being inaccessible due to ambiguity.
> I'm very rusty when it comes to inheritance and pointers, so I'm here
> to ask some questions...
>
>
> 1. Can I just remove SimulatorAccess as a public member of my class
> template to resolve this ambiguity? This seems like a bad idea, but I
> don't know enough about ASPECT's internal workings to be sure.
>
>
As Wolfgang mentioned this should work. However, there seems to be a
confusion about the meaning of 'public member' in your question. If you
write

class XXX: public Utilities::AsciiDataInitial

this means (as Wolfgang mentioned) XXX is a 'child' or 'derived' class
of AsciiDataInitial (and since AsciiDataInitial is derived from
SimulatorAccess, your XXX is still derived from SimulatorAccess,
although indirectly through AsciiDataInitial). This code does not mean
XXX owns an object of AsciiDataInitial as public member.

> 2. Why does <include/aspect/material_model/ascii_reference_profile.h>
> store the ASCII data in an object called 'profile' instead of
> declaring Utilities::AsciiDataProfile as a public member? So it ends
> up calling functions like "profile.initialize(XXX)" instead of
> "Utilities::AsciiDataProfile::initialize(XXX)", for example.
>
Maybe this got already clear from my answer above, but this is exactly
what is happening. AsciiReferenceProfile is derived from SimulatorAccess
(it is not derived from AsciiDataProfile), but it stores an object (a
'member', in this case a private member) of type AsciiDataProfile.

I suspect your question goes deeper though. Probably you want to ask:
Why is InitialTemperature::AsciiData a derived class of
Utilities::AsciiDataInitial, but the material model
AsciiReferenceProfile instead owns an object of type AsciiDataProfile?
Unfortunately, there is no compelling reason for this, except we
designed it that way. To explain that better:
Utilities::AsciiDataInitial was designed by us to be a base class (= a
class to derive from) for all initial conditions plugins that take an
ascii data table and read an initial condition from the table. This is
why InitialTemperature::AsciiData "IS A" type of
Utilities::AsciiDataInitial.
On the other hand "Utilities::AsciiDataProfile" was designed as an
object that stores some data (and returns this data if asked for it),
and it was not designed to be a base class for other plugins. That is
why AsciiReferenceProfile owns such an object and asks it for
information every time it needs it.

>
> 3. I tried to mimic the above approach in my own code as well, putting
> "aspect::Utilities::AsciiDataInitial<dim> field" in the private header
> and "field.initialize(1)" in the initialize function of my material
> model, and so on. But unlike AsciiDataProfile, the initialize function
> of AsciiDataInitial contains 'this' pointers that end up pointing
> nowhere and giving me "address not mapped" errors. Again, I'm not an
> expert on pointers... Could I fix this problem without altering the
> source code, or is this just a bad approach?
>
This is not a bad approach, and might work just well. You just need to
add one line to your initialize function to make it work (this is a bit
unintuitive unfortunately):

instead of

field.initialize(1)

you can write

field.initialize_simulator(this->get_simulator());
field.initialize(1);

This should fix the "address not mapped" errors. The catch here is that
AsciiDataInitial is derived from SimulatorAccess, which needs some
initialization. For all normal plugins this is done by the core of
ASPECT, but if you add a new member object that is derived from
SimulatorAccess, you need to care for this yourself.

>
> 4. ...Is there a more sensible way to go about what I'm trying to do here?
>

I think your approach in 3. is reasonable. There is a different way as I
mentioned in 1., but which is better is not clear. If you want to look
into this, take a look at what Utilities::AsciiDataInitial actually is
and does. It is a class that itself just owns an object of type
AsciiDataLookup, which contains the data. So instead of creating a
member in your class of type AsciiDataInitial, you could create a member
of type AsciiDataLookup and implement in your material model what
AsciiDataInitial does for initial conditions. This is equivalent to what
MaterialModel::AsciiReferenceProfile does, just replacing the member of
type AsciiDataProfile by one of type AsciiDataLookup.
>
>
> I didn't want to dump a bunch of code here, but please let me know if
> my questions aren't clear enough as is, or if I'm misunderstanding
> what the ASPECT code is doing. Thanks in advance for any help!
>
I think you got really close to what you wanted to achieve already.
Sorry for the lengthy answer with lots of C++ internals, let me know if
I should repeat anything with less details.

Cheers,
Rene

>
> Marie
>
>
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel

-- 
Rene Gassmoeller
http://www.math.colostate.edu/~gassmoel/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geodynamics.org/pipermail/aspect-devel/attachments/20180201/7694a815/attachment.html>