Land Cover Manning in 2D Flow Area Destabilizes 1D/2D Model

[Scott Miller]

I have a 1D/2D model that is stable and able to handle a 50-year storm with a very steep rising limb. The default Manning value n=0.06 was applied throughout the 2D flow area. I imported a land cover layer that has Manning values that range from n=0.027 to n=0.12, and scaled those values up by 25%. The new area weighted average Manning value is n=0.078.

As a result, the model is not stable. In order to develop a hot start file I had to increase the uniform time step to 6 seconds (thetas=1), whereas 2 seconds had always worked. I’m sure the model will not handle storms at a 6 second time step. With the increased time step, and low flow hydrographs delivering flow, the 2D flow area is iterating far too much. It was usually 0 to 2 iterations during storms. Now it iterates into the high teens during low flow.

[Scott Miller]

I reduced the maximum cell size by half to 16 feet, and am using the Manning values without increasing them 25%. The uniform time step is back down to 2 seconds for developing a hot start file. The 2D flow area is iterating about 2 to 4 times instead of 14 or so times.

Slow 2D convergence is occurring during low flow conditions. The model is so slow, it will go slower than real time during a storm. Is it usually the case that applying Land Cover to specify Manning values makes 2D convergence more tenuous? Could it have something to do with the number of land cover types or granularity of the Land Cover map layer?

[Scott Miller]

I used Geometry Overrides to replace all Land Cover Manning values with n=0.08, except for on the 2D channel, n=0.028. The model did not appear to be any faster with less nominal heterogeneity.

I then reverted to the model without Land Cover, and increased the default 2D flow area Manning value to n=0.08. I defined a Manning override region on the 2D channel, n=0.028. The model is running fast again.

The values are the same in both approaches. What would it be about the Land Cover that is slow?

[Anonymous]

RAS 5.0.4 had a problem with land cover that was fixed in RAS 5.0.5.

[Scott Miller]

Running 5.0.5 now on 16 cores @ 2.3 GHz on Xeon (2.95 GHz actual). Previous attempts were 5.0.4 on 8 cores @ 3.6 GHz on Core i7, and a slower than real time on 4 core @ 2.7 GHz laptop Core i7.

The current model scenario without land cover Manning ran in 38 hours on the Xeon, and in 45 hours on the 8 core i7. At the rate the model is going at on the Xeon with land cover Manning, it will take more than 120 hours to complete four weeks of model time.

The 2D area is regularly iterating up to 4 times and the 1D reach regularly up to 2 times, with no 1D/2D flow error. This is low on a recession curve, though, and I expect it to iterate more intensively when the 100-year 4-day volume runs through.

I’m going to have to do the five scenarios without the land cover Manning. What opportunities are there to speed up the model, if I were to continue using land cover?

[Anonymous]

There is a variable time step option in 5.0.5. By adjusting the time step during the run, it might be possible to save computational time.

If you are using the full momentum for the 2D, have you experimented to see if the diffusion wave gives ok results? Diffusion wave is much faster and can handle longer time steps, but is not appropriate for all data sets. You can always run both and see how much difference it makes.

It sounds like you are already aware of the restart file option. But you might still think about whether you can use the restart file so you don’t have to run the full four week model times for each scenario.

Also, it might be the case that it would be faster if you didn’t use all the cores. I don’t have enough cores to worry about it, but I remember reading somewhere (the 2D manual?) that the sweet spot for number of cores was around 8~12.

That’s all I got for suggestions.

[cameron]

It is important to note that HEC-RAS will use half the number of cores you have on a machine if it is left at the default of using all cores. So when you say you have 16 cores, it is only using 8.

If you use a land cover dataset for manning’s or override regions it should not make a single difference if they are identical as all they do is apply a n value to the cell face.

You could do a test to see if the same manning’s are getting applied as 5.0.5 creates a final n value raster. Just do a subtraction of the two in GIS and see which areas are the same or different.

If you can identify the cells that are iterating a lot, fix them and that will help with run times. I have gotten runs that at the beginning took 12 hours to run down to 1 hour

[cameron]

One other thing you could try is adjusting the weir coefficient for the lateral structure or switching to the 2D equation option instead.

[Scott Miller]

Thank you Jarvus and Cameron. It looks like I could fine tune the Courant control and adjust the geometry or terrain to streamline the model.

I’d like to know how to identify cells that iterate the most. Maybe by reducing 2D iterations to the point that wse error warnings occur? Or maybe by switching to full momentum. I did switch from dynamic wave to full momentum and found a particular cell was problematic.

It is not clear exactly why that cell would cause problems, but, looking at the property/elevation plots nearby, it looks like the elevations may not be high enough. Is there a way in the 2D mesh to force the elevation range. Maybe the cells are too small (an attempt to limit Courant time step reduction in the tributary). Is there some way the depth on the property curve is projected from cell size and the topographical elevation range?

The variable time step is playing a part in the difference in model speed. I stopped the run described yesterday and removed the land cover. The model is running three times as fast. The first thing I noticed was that the time step did not drop to 0.5 second in the first few seconds of model time. It stayed at 1 second. I expect the uniform 0.06 Manning in the 2D flow area is subduing the Courant number somewhere.

Time could definitely be saved by lopping off the tail of the hydrograph recession and a trailing storm. It’s not necessary to model the subsequent period.

The number of math processors being used seems to be ok. Sixteen cores take 82% the amount of time eight cores do with this geometry (14,366 mesh cells).

[Anonymous]

Yes, it would be nice to know if a cell is problematic even if it doesn’t go to the maximum. As far as I know, reducing the allowed iterations to get the actual warning is the only way to do it.

It is possible that the cell that has the most problem during full momentum would also have the biggest problem with diffusion, but I’m not sure I would assume that.

I’m not sure what you are driving at with the elevation and the property curves. The property curves are for when the cell (or face) is partially wet. You do not need to continue the property curve after it is fully wet (once it is fully wet it is a simple computation).

If you have some cell where only a corner of it is wet, especially if using full momentum and it is high velocity, that can drive iterations. Tweaking the mesh can help in that case. Otherwise, it isn’t usually clear to me why a given cell is iterating a lot. But if I find one that is, changing the mesh in that location can sometimes help.

At first I thought it was a little strange your model had so much more problem with land cover, but that is a fairly big change in Manning’s n.

Once you turn on the variable time step option, RAS will generate a Courant map. It has to be added as a new layer.

[Scott Miller]

You do not need to continue the property curve after it is fully wet (once it is fully wet it is a simple computation).

Of course, that ought to have been obvious.

The mesh cell that iterated a lot under full momentum is configured as you describe. Its downstream edge hangs across the edge of a headcut-like divot in the relatively steeper tributary. That can easily be fixed.

Regarding the land cover, there is quite a spread in values. I used Chow’s “normal” values for channel and floodplain. As the 2D calculations go, I figure there are flow rate differentials among pastured, mowed, and forested areas that simply iterate more to converge.

Thank you for pointing out the Courant map. It’ll be helpful for adjusting the time step control.

[Author]

Posts