geoclaw icon indicating copy to clipboard operation
geoclaw copied to clipboard

Level specific wave tolerance

Open akshaysripada opened this issue 8 years ago • 5 comments

Wave tolerance is now set to be level specific, very similar to the speed refinement. If the number of wave tolerance values are less than the max amr level specified, the last value of the wave tolerance is used for the remainder of the levels.

akshaysripada avatar Jan 18 '17 00:01 akshaysripada

Does this then work with only a scalar specification of the wave_tolerance in the setrun.py files?

mandli avatar Jan 18 '17 16:01 mandli

Yes it will work for a scalar representation since refinement_module.f90 will read the values in refinement.data file for the wave tolerances and store it in an array regardless of number of values provided.

akshaysripada avatar Jan 18 '17 23:01 akshaysripada

@mandli: This wave_tolerance logic is based on how speed_tolerance is handled, but I don't understand how this is supposed to be used exactly.

I would have thought that speed_tolerance[m] is only used to determine whether to refine a grid at level m to level m+1. But instead, the way it is written to loop over m=1,mxnest, I think that level L is refined to level L+1 if the speed is at least as great as any of the values speed_tolerance[m] for m >= L.

Is this really what's intended? If the tolerances are non-decreasing then I think it has the behavior I expect but if speed_tolerance[m] > speed_tolerance[m+1] for some m then I think speed_tolerance[m] is never actually used as a cutoff at any level and so this is just confusing.

Other minor problems with flag2refine.f90:

  • tab characters rather than blanks starting some lines
  • Print statements should be removed.

Also we probably want to modify data.py to initialize wave_tolerance consistent with how speed_tolerance is initialized, which is currently self.add_attribute('speed_tolerance',[1.0e12]*6), but actually I think it would be better to leave self.add_attribute('wave_tolerance',1.0e-1) alone and change speed_tolerance to a scalar, which works fine and seems more logical than setting the same value 6 times (when the user might have more than 6 levels).

rjleveque avatar May 07 '17 18:05 rjleveque

@akshaysripada Can you take care of some of these suggestions from Randy? I am a bit confused as well about the way you implemented this but I need to look at a bit more before I have a suggestion.

mandli avatar May 08 '17 19:05 mandli

So looking carefully at the code I think there are a couple of modifications and one question that @rjleveque brought up:

  • The loops that determine the particular tolerance to use need to be outside of the loops over cells as these are only needed once for each grid.
  • Move the if statement into the refinement_module where this can be done once.
  • On the latter if the criteria are not monotonic I am not sure what the best thing to do is. One reason we only checked this once was to reduce the amount of checking but we could always look for the threshold for all levels just to make sure.
  • Need to add the data.py changes.

mandli avatar May 09 '17 00:05 mandli