Make several setrun inputs more flexible

[rjleveque]

There are several inputs in the the typical setrun.py that could be enhanced by allowing the user to set more related options.

topofiles

For example, rundata.topo_data.topofiles is currently a list of lists, each of which has a rigid form [topotype, minlevel, maxlevel, t1, t2, fname]. There are other options we might want to set, see, e.g. #296.

I suggest we define a new class topofile and an object of this class would have attributes topotype, fname, etc. Then it would be much easier to add new attributes later (with some default values if not set) with no backward compatibility issues in setrun.py.

For backward compatibility with the current style, I suggest we allow rundata.topo_data.topofiles to be a list of objects, each of which is either a list with the current format or a new topofile object. When setrun is processed, any lists in the current format could be converted to topofile objects.

Some new attributes we might add:

• extent and stride as suggested in #296,
• xshift, a value to shift the longitude from the input file by (e.g. 360 or -360 if the DEM is in longitude W and the simulation is being down in longitude E or vice versa).

We might also want to keep minlevel, maxlevel, t1, t2 as attributes that are allowed but not encouraged since in general it seems confusing to users to have these in addition to regions. So they might have the default values 0, iinfinity, -rinfinty, rinfinity respectively.

regions

We could do the same for rundata.regiondata.regions, allowing this to be a list of objects, each of which is either a current-style list [minlevel,maxlevel,t1,t2,x1,x2,y1,y2] or an object from a new class region that has attributes minlevel, etc. This would allow adding some new attributes that have been discussed, e.g. specify a different flagging method or tolerance for each region.

[rjleveque]

Note deprecation of minlevel,maxlevel in topo and dtopo file specification in https://github.com/clawpack/geoclaw/pull/487

[mandli]

I am all for this, I think we have even had a few tries at this. Maybe we try and build out a prototype that also needs to have the backwards capability?