Write a postprocessor that outputs the elevation from the dynamic topography/mesh movement scheme

[bangerth]

From an email by @gassmoeller to Payman Janbakhsh on the mailing list:

surprisingly (also to me) ASPECT currently does not have a postprocessor that outputs a map of the topography of a deformed mesh. The closest thing is the visualization/depth postprocessor that will output the depth of every point of the domain. However, the depth() function of the geometry model is bounded to (0,maximal_depth), so it will not output positive topography correctly. If you would be willing to spend some time helping create a postprocessor for topography that would certainly be a useful addition. Let us know if you would have the time and willingness to do so, we could then discuss the details of the implementation (always easier to discuss that first, before writing something and then reworking it many times).

Depending on your intended purpose you would either need to create a general postprocessor that outputs the topography into a separate file (as for example postprocess/heat_flux_map), or a visualization postprocessor that adds another field to the .vtu output of the solution (as for example postprocess/visualization/depth). However, there might be some challenges to make it work for arbitrary model geometries.

[ian-r-rose]

This is something that used to exist (it was very similar to
heat_flux_map), but I think got left behind in the big merge of the free
surface implementation. This was mostly an oversight on my part.

The way topography is calculated in the topography postprocessor (which has
always been an unfortunate name due to confusion with dynamic_topography)
is that it references the topography to some datum that depends on the
geometry (i.e., outer_radius for spherical shells, height for boxes). If
the geometry model is not something that the topography postprocessor knows
how to query for the reference surface, then it will fail.

All of this is to say that a merger of the code from the topography
heat_flux_map postprocessors should to the trick.

On Thu, Nov 10, 2016 at 8:57 AM, Wolfgang Bangerth <notifications@github.com

wrote:

From an email by @gassmoeller https://github.com/gassmoeller to Payman
Janbakhsh on the mailing list:

surprisingly (also to me) ASPECT currently does not have a postprocessor
that outputs a map of the topography of a deformed mesh. The closest thing
is the visualization/depth postprocessor that will output the depth of
every point of the domain. However, the depth() function of the geometry
model is bounded to (0,maximal_depth), so it will not output positive
topography correctly. If you would be willing to spend some time helping
create a postprocessor for topography that would certainly be a useful
addition. Let us know if you would have the time and willingness to do so,
we could then discuss the details of the implementation (always easier to
discuss that first, before writing something and then reworking it many
times).

Depending on your intended purpose you would either need to create a
general postprocessor that outputs the topography into a separate file (as
for example postprocess/heat_flux_map), or a visualization postprocessor
that adds another field to the .vtu output of the solution (as for example
postprocess/visualization/depth). However, there might be some challenges
to make it work for arbitrary model geometries.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1270, or mute the thread
https://github.com/notifications/unsubscribe-auth/AFdoN0K6343qK4W8Cq71BeeVTm094HBhks5q800AgaJpZM4Ku5M3
.

[gassmoeller]

I agree with @ian-r-rose that a merged version of topography and heat_flux_map is the easiest way to implement this.
However, I wonder if it would be better to implement a new function for geometry models that handles the computation itself, because it is a property of the geometry model if something is below or above this datum. This way the postprocessor does not need to know all geometry models. It is a bit unfortunate that GeometryModel::Interface::depth() is bounded to 0,max_depth. Should we introduce a new function GeometryModel::Interface::unbounded_depth or distance_to_surface (although it is not a distance, I am lacking a good name here)?

[bangerth]

Yes, I think this ought to be done in a new geometry member function. distance_to_surface has the disadvantage that it "distance" is the same for depth and elevation. That would suggest height_above_surface. But that ignores the fact that the "surface" is, computationally, defined by the deformed domain, and we want the original domain. So maybe height_above_original_surface?

[lkaratun]

Hi,
please have a look at #1980. Thank you!