[aspect-devel] Tracking time-dependent properties through compositional fields (general discussion)

[John Naliboff]

Hi Juliane, Hi Wolfgang,

Thanks for the detailed replies!  

Wolfgang - The ‘volume fraction’ I was referring to is the percentage of a specific composition in an element, which is then used to compute the overall (averaged) material properties for a composition-dependent material model.  The terminology is specific to a section of code in the composition-dependent material models (multicomponent, diffusion_dislocation, etc).  

Juliane - thanks for the tip, that seems like a straightforward and clear way to separate compositional fields in the material model.  So far, I’ve just assigned compositional fields associated with strain a value of ‘0’ in the volume fraction section of the code.  This was relatively easy to automate given the relationship between the model dimension and the number of required compositional fields for the strain.

I’ll keep thinking over ways to make the separation of compositional fields (tracking strain/etc vs affecting material behavior).  I’d like to make this is a simple as possible so that users don’t accidentally mix up what fields are doing what.

Thanks again for the input!

Cheers,
John

*************************************************
Assistant Project Scientist, CIG
Earth & Planetary Sciences Dept., UC Davis





> On May 28, 2016, at 3:35 AM, Juliane Dannberg <dannberg at gfz-potsdam.de> wrote:
> 
> Hi John,
> 
>> 1.  In finite_strain.cc, each component of the strain tensor is assigned to and advected with a unique compositional field via the reaction term.  If one wishes to track additional properties, say CPO and melt, this will require additional unique compositional fields for each component.  At some point, will the advantages of using compositional fields over tracers be negated if too many compositional fields are present?
> As Wolfgang already said, Rene has the most experience with the tracers in Aspect, so he will probably be able to say more about the point at which tracers become more efficient than fields (which also depends on the application/geometry/advection scheme of tracers etc.).
>> 
>> 2. In finite_strain.prm the compositional fields for each component (4 total) of the 2-D strain tensor are assigned a value of 0 under the initial conditions section.  My interpretation is that this procedure allows the fields to track the strain through the reaction term, but the "volume fraction” of these fields in each cell is still effectively 0.  Is this interpretation correct?  If it is correct, that means composition dependent material models (ex: multicomponent.c) following this approach will not be affected by the compositional fields tracking strain unless they specifically use the reaction terms.
> You already said it yourself -- if you want to use strain tracking together with a material model that uses additional compositional fields to track other things than the finite strain, you have to adapt the material model so that it knows what to do with each of the compositional fields.
> The easiest way to do that is probably by using the "names of fields" feature. In the input file, you can assign a name (e.g. "basaltic_crust", or "strain_xx") to a compositional field, and in the material model you can get the index of a field with a particular name using the introspection class (this->introspection().compositional_index_for_name("strain_xx")). This way, you can keep the material properties from e.g. multicomponent.cc, and add the influence of finite strain tracking only where you want.
> In this case, the interpretation of what the value of a field means would also be different, i.e. for the finite strain what the field contains is the finite strain instead of a volume fraction of a certain material. That is totally fine, as long as your material model keeps track of what to do with each of the fields.
> 
> Best,
> Juliane
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel

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