Pull requests

#164 Merged
Repository
samskillman
Branch
week-of-code
Repository
enzo
Branch
week-of-code

Second derivative refinement criteria

Author
  1. Sam Skillman
Reviewers
Description

This adds a new refinement criteria based on the second derivative of any field, normalized by the first derivative. This is useful for identifying shocks and other strongly varying gradients. The MinimumSecondDerivativeForRefinement can be specified for each field, and is bounded by [0,1]. SecondDerivativeEpsilon is used to ignore small fluctuations and avoid refining in un-interesting locations. SecondDerivativeFlaggingFields is an array of field indices that are examined for refinement. This is based on a technique proposed by Loehner et al 1987, and is outlined in the FLASH4 user guide here.

This also includes a quick fix for use-mpi-no to use ReturnWallTime instead of MPI_Wtime in EvolveLevel_RK2.C

Update 1: Adding documentation, setting the NumberOfFields to 1 (unless the user specifies multiple fields in the SecondDerivativeFlaggingFields parameter (a list of field indices). Also cleaned up the docs for the refinement methods into a table. The weird double-column format was getting out of hand.

Update 2: My attempt to set the default number of fields to 1 was incorrect. Now this defaults to checking one field unless a field is specified. If so, it loops through all fields to find the correct ones to use.

  • Learn about pull requests

Comments (6)

  1. Nathan Goldbaum

    Hey Sam, sorry to butt in without having been explicitly added as a reviewer, but can you edit the refinement parameter docs to add some descriptions of the new refinement parameters? This looks great by the way, seems like a very nice addition to the code.

  2. Greg Bryan

    I agree with Nathan -- documentation is missing. However, everything else looks good. I didn't test the code, but I did look it over, and I see that you removed the duplicate read of MinimumSlopeForRefinement.

  3. Brian O'Shea

    Hi Sam, I looked through the code and everything seems reasonable to me and as far as I can tell reproduces equation (33) from the Enzo method paper.

    A question: would it make sense to have the default NumberOfFields be 1 or 2, and force the user to add more? I can see how refining on velocity in particular would lead to insanity.

    Also, when you write the docs, please make sure to mention what a reasonable value for the MinimumSecondDerivativeForRefinement field would be!

  4. Sam Skillman author

    Thanks for the comments, all. I'll add the docs on my upcoming plane flight. Is it worth reproducing the rather nasty equation from the method paper in the docs themselves? Brian O'Shea I think that's probably wise to only do that. Currently that will be the case for a few of the problem types. I think I was just copying what was done for refine by slope. I'll set it to one field since in a few problem types I remember velocity being the second field.