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

Timo Heister heister at clemson.edu
Tue Apr 19 10:27:14 PDT 2016


Hey Harsha,

I would go a different route for the reasons Rene already pointed out:
you won't get back the same solution vectors because visualization is
just a linear approximation of the variables. It should be relatively
easy to modify the checkpointing feature to write out the solution
vector in each computed timestep into a different file. That way you
can load it back in and get identical results to the original run.

Best,
Timo



On Tue, Apr 19, 2016 at 10:27 AM, Rene Gassmoeller
<rene.gassmoeller at mailbox.org> wrote:
> 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
>
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel



-- 
Timo Heister
http://www.math.clemson.edu/~heister/


More information about the Aspect-devel mailing list