[aspect-devel] Prescribed stokes flow and the time step

[Rene Gassmoeller]

Hello Harsha,
let me ask a question before offering advice to the wrong problem. By
"not in sync" you mean the particles in your new model with prescribed
flow do not  follow the flow of the "old" model without prescribed flow?
This indeed is likely caused by two approximations in the 'ascii data'
prescribed Stokes plugin. However, I would not formulate in the way that
the problem is the difference of "the timestep" of the two models. The
timestep is always computed according to the flow in the model, so in
reality it is likely the flow that is changing. When outputting the
solution into vtu, reformatting and then using it for a new run there
are some approximations that will simply lead to small differences
between the two models, but I am also afraid that we will have to live
with a small difference. However we can think about the places where the
approximations are made and how to minimize the difference:

1. The vtu output is written at mesh node locations (is your mesh
uniform?), while the solution vector is stored as degrees of freedom
information. While rerunning the model the velocity will be interpolated
linearly between the given positions in the file, assuming that the file
contains a uniform mesh. Additionally outputting data from paraview
often leads to a reduced accuracy (it tends to output data with only 5-6
significant digits). Both of this will lead to a slightly different
flow, and therefore change the timestep (therefore the 80,200 timestep
of your restart model will be at a different time than the original
model). However the particles should follow this 'interpolated' flow as
accurately as their integration scheme allows. There is not much I can
see to circumvent these approximations.

2. I am not sure how you read the vtu output into the new model, but as
far as I remember the current 'ascii data' plugin expects data at
equidistant times, which will not be the case if you output every
timestep (and even if you prescribe output every X time, ASPECT will
output the timestep after this time is reached, so you will have slight
variations in the intervals as well). Therefore you would need to either
change the 'ascii data' plugin to also allow for non-equidistant
intervals (e.g. reading the times from the same file as we do for the
number of nodes in the grid, which is marked by the "# NODES: X Y"
string), or you would need to interpolate the dataset onto equidistant
times (another source of differences between your original model and new
model). If you would like to go for the first option let me know, and we
can discuss the format of the change, it might also be beneficial to all
the other 'ascii data' plugins, so we might as well make it available to
all of them. They are all derived from the same base class anyway.

3. Setting the 'Start time' parameter in your model should only be
necessary, if the 'ascii data' plugin needs it to find the correct flow
file. Otherwise the parameter should not have any influence on the model
that I can currently think of.

4. Concerning using the vtk library: How exactly do you intend to use
the library? As part of your script that prepares the ascii data files
for your model run? Or do you intend to link it into ASPECT itself? This
sounds like too much effort for the given problem, I would definitely
favor a solution where we can keep all the data we need inside of the
data files.

Hope to have given you some ideas, let me know what kind of approach you
would favor so we can discuss how to incorporate it best.

Best regards,
Rene

On 04/19/2016 02:32 AM, Harsha Lokavarapu wrote:
> Hi all,
>
> I am a junior specialist at CIG and recently, we have accumulated solution data (VTU format) for a 2-D domain of 4root(2) by 1 at a Rayleigh number of 1e7 on Stampede.
> This was ten days worth of computational time on 256 processors totaling approximately 3 TBs of solution data. Given the data, we reran aspect using 
> the prescribed stokes plugin starting with the solution data at the 80,000th time step number all the way to the 90,000th time step number of the run on Stampede with a layer of uniformly placed particles in the top three percent of the domain. After examining the output, we immediately saw that the flow and particles were not synced. We have narrowed the problem down to the difference in the time step (or delta T between two consecutive time step numbers) between the original and the second run.
> One attempt at a solution was to set the start time of the second run to the same value as that of the time at the 80,000th time step number in the statistics file of the first run. Although initially there was little to no deviation in time step between the two runs, by the 200th time step number, it was clear that this wasn’t viable. The other thought we are contemplating is to read in an ascii file that consists of the time step at each time step number as part of the prescribed stokes plugin. By then setting the start time as well and adding the time steps for each time step number, we are certain that the displacement of particles at each time step number will be correct even if we begin at any time step of the original run. Is this the right method of solving this problem?  Does such functionality already exist within ASPECT? If not, I could really use another perspective on this.
>
> Thanks for reading,
> -Harsha
>
> P.s.
>
> Also, another thread I am investigating is using the VTK library to extract the time from each solution.pvtu file. All I have found are meta data with "modified time” field being the closest to what I am looking for. Do you have experience with using the VTK library?
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel