[aspect-devel] A bug in gplates plugin

Sun Nov 2 16:29:48 PST 2014

Hi Rene,

Sure. I will send a new pull request for this.

Regards,

Siqi

On Mon, Nov 3, 2014 at 4:41 AM, Rene Gassmoeller <rengas at gfz-potsdam.de>
wrote:

> Hi Siqi,
> I have looked a bit into the interpolation issue and it seems indeed
> that the previous implementation did a better job at avoiding the
> gplates grid effects. Since GPlates now also has the interpolation
> possibility, I would not oppose switching back to the old formulation,
> however this is a bit involved, because I did some changes in the
> meantime that are unrelated to this. So simply reverting gplates.cc and
> gplates.h will also revert these improvements and bugfixes. Do you want
> to sort out the stuff and make a new pull request, or should I take a
> look into it in a while when I have some more time?
>
> Best,
> Rene
>
> On 10/27/2014 05:25 AM, Siqi Zhang wrote:
> > Hi Rene,
> >
> > About the bug, here is a simplified parameter file to reproduced this bug
> > (as shown in Pole_velocity_bug). Using velocity data from gplate 1.3
> with 4
> > degrees resolution.
> > I have already send the pull request.
> >
> > As for the plate deformation problem, I don't think changing
> interpolation
> > width will solve it.
> > Here is an example of the strain rate (Strain_rate1.png), using
> > interpolation width=0.
> > The resolution of gplate data is 4 degrees, and computation grid is
> refined
> > 5 times which the resolution is much better than the gplate data.
> > In comparison, if using the old lat-lon interpolation (using cartesian
> > velocity instead of spherical velocity), the strain rate looks much
> better
> > (Strain_rate2.png). It seem working well for my problem.
> > And it doesn't seem to have problem with convergence for my test, even
> with
> > strain rate dependent rheology.
> >
> > And it seems that the gplate 1.4 has an option to do some smoothing while
> > writing the gpml file. May be we don't need to do it here.
> > Or another alternative will be only do smoothing at the plate boundary
> > which can be determined by checking the velocity gradient on lat-lon
> grid.
> >
> > Regards,
> >
> > Siqi
> >
> >
> > On Mon, Oct 27, 2014 at 11:55 AM, Siqi Zhang <siqi.zhang at mq.edu.au>
> wrote:
> >
> >> Hi Rene,
> >>
> >> I am using the development version, and data from gplate 1.3. (gplate
> 1.4
> >> has the similar problem)
> >> And the problem only appears while using coarse gplate data grid and
> more
> >> refined surface grid. (only points in the first and last latitude grid
> will
> >> be affected).
> >> I have put pull request for this, please take a look.
> >>
> >> Thanks for the clarification of the interpolation, I will try
> >> interpolation width to 0 see if it solve the deformation problem.
> >>
> >> Regards,
> >>
> >> Siqi
> >>
> >> On Mon, Oct 27, 2014 at 9:44 AM, Rene Gassmöller <rengas at gfz-potsdam.de
> >
> >> wrote:
> >>
> >>> Hi Siqi,
> >>> thanks for posting these problems. Could you please post the aspect
> >>> version and gplates version you use? I fixed some problems with the
> poles
> >>> and 2d models since the 1.1 release, but maybe there is still a bug (as
> >>> always ;) ). It might also be related to the change in the gplates
> format
> >>> between version 1.3 and 1.4. Could you sent a simple input file that
> >>> reproduces the problems? If you already have the fixed code, then sure
> - go
> >>> ahead and sent a pull request, I will take a look at it.
> >>>
> >>> In fact the interpolation we currently use is a moving window average
> >>> with no distance weighting. The weighting you see in the code is to
> account
> >>> for the different area each point represents in a latitude-longitude
> grid
> >>> (sine of latitude).
> >>> I think the reason for switching from latlon interpolation to cartesian
> >>> moving window was that I introduced this interpolation mostly for
> smoothing
> >>> purposes, not so much for the most accurate velocity at a point, but I
> see
> >>> your point that this might be important for many models. Would it help
> your
> >>> purpose to set the interpolation width to 0? Then there should be no
> >>> interpolation at plate boundaries.   Or do you mean that with the
> current
> >>> interpolation there is actually deformation occuring within plates?
> That
> >>> would need to be fixed of course. I would just like to keep the
> possibility
> >>> to smoothen the surface velocities as it helps convergence in my
> models. We
> >>> can certainly discuss better interpolation methods or provide several
> >>> options.
> >>>
> >>> Best
> >>> Rene
> >>> ------------------------------
> >>> Von: Siqi Zhang <siqi.zhang at mq.edu.au>
> >>> Gesendet: ‎24.‎10.‎2014 02:55
> >>> An: aspect-devel <aspect-devel at geodynamics.org>
> >>> Betreff: [aspect-devel] A bug in gplates plugin
> >>>
> >>> Hi All,
> >>>
> >>> I found a bug in the gplates plugin.
> >>> While the gplate gpml file set longitude to 0 for all points at the
> pole,
> >>> the plugin assume the longitude vary from 0~360 for the grid points at
> two
> >>> poles. This gives the wrong cartesian velocity while reading the data
> and
> >>> result weird surface velocity field around the pole. I can create a
> bug fix
> >>> for this if Rene agrees.
> >>>
> >>> And I have another question regarding the gplate plugin for Rene.
> >>> I have noticed that the interpolation method of this plugin has changed
> >>> from latitude-longitude grid interpolation using spherical velocity to
> >>> distant weight interpolation using cartesian velocity. I totally agree
> that
> >>> we should do interpolation using the cartesian velocity, but is there
> any
> >>> particular reason to use the distant weight instead of using four
> points
> >>> bilinear interpolation on the latitude-longitude grid?
> >>> Because while using the new interpolation in 3D model, I found some
> >>> artificial strain rate within plate, it gives me some trouble while I
> am
> >>> also using yielding stress in the rheology. After I reverse back to
> the old
> >>> grid approach and interpolate using the cartesian velocity, it seems
> >>> working better. Although it is not completely removed, the artificial
> >>> strain rate is much less than the new interpolation approach. I wonder
> if
> >>> anyone using this plugin experience the similar problem and if we need
> the
> >>> change the interpolation method again.
> >>>
> >>>
> >>> Regards,
> >>>
> >>>
> >>> --
> >>> Siqi Zhang
> >>>
> >>> Research Associate
> >>> ARC Centre of Excellence for Core to Crust Fluid Systems (CCFS)
> >>> Department of Earth and Planetary Sciences
> >>> Macquarie University
> >>> NSW 2109
> >>>
> >>> Telephone: +61 2 9850 4727
> >>> http://www.CCFS.mq.edu.au
> >>> http://www.GEMOC.mq.edu.au
> >>>
> >>> _______________________________________________
> >>> Aspect-devel mailing list
> >>> Aspect-devel at geodynamics.org
> >>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
> >>>
> >>
> >>
> >>
> >> --
> >> Siqi Zhang
> >>
> >> Research Associate
> >> ARC Centre of Excellence for Core to Crust Fluid Systems (CCFS)
> >> Department of Earth and Planetary Sciences
> >> Macquarie University
> >> NSW 2109
> >>
> >> Telephone: +61 2 9850 4727
> >> http://www.CCFS.mq.edu.au
> >> http://www.GEMOC.mq.edu.au
> >>
> >
> >
> >
> >
> >
> > _______________________________________________
> > Aspect-devel mailing list
> > Aspect-devel at geodynamics.org
> > http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
> >
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>

-- 
Siqi Zhang

Research Associate
ARC Centre of Excellence for Core to Crust Fluid Systems (CCFS)
Department of Earth and Planetary Sciences
Macquarie University
NSW 2109

Telephone: +61 2 9850 4727
http://www.CCFS.mq.edu.au
http://www.GEMOC.mq.edu.au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geodynamics.org/pipermail/aspect-devel/attachments/20141103/56e41056/attachment.html>