You are here

Another Bathymetry file problem

I'm setting my model up so that I have a narrow layer 25 feet below the surface for accurate measurements at that point, as there is a slight thermocline layer the measurement point is in the middle of. Therefore, my bathymetry file has layer as such: 0.762 0.762 0.762 0.762 0.762 0.762 0.762 0.762 0.762 0.762 0.712 0.11 0.712 0.762 0.762 0.762 0.762 0.762 However, when the program runs it produces layers as such: 0.762 0.741 0.762 0.762 0.762 0.762 0.762 0.762 0.762 0.737 0.411 0.411 0.737 0.762 0.762 0.762 0.762 0.762 The 0.11m layer is being ignored and broader layers being put in its place. I also noticed that the run time is substantially longer than it was previous to the thin layer's addition. Any idea why this could be happening? Thanks.
Forums: 

I am confused by why the layer widths would be ignored or have different values. How are you checking how the values are read in? Certainly if you run the preprocessor the pre.opt file gives some of the bathymetric data. I would check how your bathymetry file looks in the GUI first. Then if you have a Fortran compiler run the preprocessor in debug mode and make sure the file is read in correctly, i.e. check right after the bath file is read in. The reason the model has slowed down is because the change in model layer widths from one layer to the next can introduce instabilities in the model (especially is you narrow for one layer and then widen it again). In the control file turn on the function that writes out time step violations (under Hyd Print) to the snapshot file and then look in the output file to see if you have time step violations at this location. Good luck. Rob

I ended up changing the format to just have equal layer widths throughout of ~0.38m, as I could not figure out why the program was changing the data. I do have one more anomaly. Using these smaller layers, I ran the program again and obtained some odd spr.opt data. The elevation of all the layers would randomly change by 0.001 meter, going from 141.912 to 141.913, back and forth seemingly at random throughout the timesteps. Do you know what could be causing this?

I believe this may be due to rounding of the last decimal place. This is more likely if there is a slope. I hope this helps. Cheers, Rob