[aspect-devel] A follow question from the webinar ...
jbnaliboff at ucdavis.edu
Fri Nov 11 10:33:43 PST 2016
Thanks for the detailed reply and copying this to the developer list, definitely the right place for it.
Everything you outlined below makes sense in terms of reasons for sticking with the current active particle method (i.e. interpolate once). Many of the models I ran require a large number of non-linear iterations, which as you point out is likely to slow things down.
Admittedly, I have not compared the memory requirements between active particles and ‘regular’ compositional field method in a rigorous manner. My experience was that for a 3D model the memory jumped noticeably, but it was long enough ago that I do not know if the version of ASPECT I used had pull request #1155 incorporated.
Hopefully before AGU I will have the chance to do a rigorous comparison between the two methods. For the purposes of examining memory requirements , I think initial comparisons should have the same number of particles per cell as integration points. Something to discuss in more detail later on.
Thanks again for the reply and for the webinar yesterday!
Assistant Project Scientist, CIG
Earth & Planetary Sciences Dept., UC Davis
> On Nov 10, 2016, at 4:56 PM, Rene Gassmoeller <rene.gassmoeller at mailbox.org> wrote:
> Hi John,
> let me copy this mail to the developer list, because it is a reasonable
> question, and others might profit from the discussion as well.
> What you propose is already possible, just not the default way. You can
> access the particles from the outside (see
> source/postprocess/visualization/particle_count.cc for an example), and
> you can either implement your own averaging scheme, or ask the particle
> world for the selected interpolator (World::get_interpolator()).
> That being said, I am skeptical you can do better that way for two reasons:
> - The memory requirement of ASPECT mainly comes from the space needed
> for the matrices, but if you select to advect a compositional field by
> particles then we do not assemble or reserve the space for this block of
> the system matrix (that was a problem in the beginning but was fixed a
> while back by @klass4kayaker in pull request #1155). The solution vector
> itself should not need much memory.
> - The reason we interpolate the properties once and then access them
> like a compositional field is that the interpolation is expensive
> compared to the evaluation of this field at a certain position. If you
> directly access the particle data you will need to do the interpolation
> many more times (e.g. once for the assembly of the Stokes system, once
> for other advection systems, once for the postprocessors, ...). Maybe it
> can be similar in speed if the interpolation is fast, but I doubt it can
> be faster.
> Feel free to give it a try, but I would not expect many benefits (except
> you do not need to rely on the finite element discretization of the
> compositional field, but then you introduce that again, because the
> velocity you are solving for is discretized the same way).
> On 11/10/2016 05:28 PM, John Naliboff wrote:
>> Hi Rene,
>> I actually have a follow up question from the talk. To reduce memory
>> requirements, would it be reasonable in the future to have material
>> models that access particle information directly rather than through a
>> compositional field?
>> In this scenario, a particle interpolation scheme would be called
>> every time the material model needs particle information interpolated
>> to a quadrature point.
>> I suppose this could noticeably increase the computational time if one
>> has to do lots on non-linear iterations. Trade-off between
>> computational time and memory requirements. For 3D models, I imagine
>> the memory requirements may be a bigger issue.
>> Gerry Puckett and I have been discussing this after running into
>> memory issues with 3D models.
>> Anyhow, thanks again for the great talk!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Aspect-devel