[aspect-devel] "Not converge" problem with variable viscosity.

[Scott King]

This is helpful, but it is important to remember that CitcomS solves for pressure,
then uses the pressure field to solve for velocity.  Thus it is really going to be hard 
to determine equivalent tolerances because the matrices come from entirely different
equations, let alone different element types.

I’m somewhat less concerned with a point-wise comparison of solutions, as this
can be very tricking for the reasons you point out, amongst others.   For many 
problems there are well-defined global diagnostics, Nusselt number, rms velocity,
horizontally averaged functions.  

I think a potential approach that addresses my interests as a researcher is to look at 
each method separately and vary the resolution and tolerance for a set problem 
(problems) and look at how these changes the characteristics that are typically used 
in analysis.   The compare the ensemble of solutions.  Trying to map the two codes 
one to one with corresponding grid and tolerance is likely to be unproductive.  Besides
I think we really want to know how much extra it ‘costs’ to increase the resolution or
to increase the tolerance, or whether doing so changes any of the diagnostics that
one typically uses for analysis.


> On Sep 8, 2015, at 8:56 AM, Rene Gassmoeller <rengas at gfz-potsdam.de> wrote:
> 
> Let me follow up with a few points to this discussion, because it is
> something I thought about for a while and talked about with Juliane
> Dannberg, Max Rudolph and Menno Fraters just a few days ago. Currently,
> we have no quantitative answer to the question how Citcom(S or CU) and
> ASPECT compare in speed or accuracy, because the benchmark is a bit
> involved due to the different techniques and meshes. As Wolfgang
> mentioned, the same number of elements will in general give a huge
> difference in number of degrees of freedom, properties of the matrices,
> computing time, and accuracy. Therefore, to compare the speed in a fair
> way there are several criteria to be considered:
> 
> - Checking the computing time for the same number of degrees of freedom
> (e.g. 32x32x32x12 for CitcomS, which is approximately 33x33x33x12x5 = 2
> mln DOFs and global refinement 3 for ASPECT, which is around 1.7 mln
> #DOFs). The difference will be the perceived slowdown of ASPECT compared
> to Citcom, because we will likely want to achieve the same mesh
> resolution in our output files (see below for a discussion of the
> resolution in output files). For a true comparison, one would also need
> to check the size of typical timesteps of a problem with multiple timesteps.
> 
> - Computing time to achieve a certain accuracy (since one higher order
> DOF gives more accuracy than one lower order DOF as mentioned by
> Wolfgang). This would need to be done by comparing the residual to a
> known solution for different resolutions in both codes. This is even
> more complicated, if one wants to consider AMR (for the beginning I
> would suggest to skip AMR checks).
> 
> - Making sure both codes use the same residual tolerance of the linear
> solver as Wolfgang mentioned. This will involve checking that the
> residual is calculated in a similar way, that the solvers use the same
> tolerances, and that CitcomS actually reaches this accuracy (if I
> remember right, CitcomS used to accept a solution as soon as the
> residual did not improve by a certain rate).
> 
>> Comparing the number of nodes in the output file from Aspect with the number 
>> I calculate from the CitcomS grid, I think that the global refinement 4 is about 
>> equivalent to the 32x32x32x12 CitcomS grid while global refinement 5 is equivalent to 
>> the 64x64x64x12 element grid.  
> 
> This is true considering the default visualization output. However, even
> this comparison is more complicated. Unfortunately ParaView only
> supports the visualization of linear elements, which means visualizing
> an quadratic element with Paraview will loose a lot of accuracy compared
> to the internal representation. We tried to circumvent this by
> introducing the "Set interpolate output = true" option in the
> visualization plugin, which will evaluate the solution fields on a mesh
> with twice the resolution. You can think of this as sampling a quadratic
> function at two times the number of points and then linearly
> interpolating between these points (there is an explanation incl a
> figure in the parameter section of the manual). This will generally
> allow for a better comparison between the solutions, and the mesh is
> then similar between a global refinement of 3 in ASPECT and a 12x32^3
> grid in CitcomS, analogue to the number of DOFs.
> 
> I hope that helps in getting some answers, and would be happy to help or
> contribute to a discussion.
> 
> Best
> Rene
> 
> On 09/06/2015 11:36 PM, Wolfgang Bangerth wrote:
>> 
>>> I think we had the same number of elements but the linear vs. quadratic
>>> elements is/was an issue that I'm not sure we factored in correctly.
>> 
>> It has a large effect since for quadratic elements the matrix is so much
>> fuller. For example, for Q1xQ1 elements with Stokes in 3d, you typically
>> get 108 entries per row. For Q2xQ1 elements, you get 402. So just
>> reading once through the matrix will cost you 4 times as much time.
>> Given that the matrix is also worse conditioned makes the situation even
>> slower.
>> 
>> 
>>> In fact I asked Shangxin to set up and run the low Ra l-3,m=2 problem not
>>> so much to look at time but to begin to look at accuracy.   But I have
>>> not
>>> seen his results yet.  The goal was to try to do this on various grids
>>> and
>>> see 1) how it compares with CitcomS and 2) how the various diagnostics
>>> compare on different levels of refinement.
>> 
>> I'd be curious to see what you find out with this. I'm not saying that
>> ASPECT may not be slower than it should be, but it would indeed be
>> interesting to see a comparison with Citcom that takes into account the
>> accuracy you get from the result, and both codes using linear solver
>> tolerances that are comparable.
>> 
>> Best
>> W.
>> 
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org <mailto:Aspect-devel at geodynamics.org>
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel <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/20150908/763fae6e/attachment-0001.html>