Denim Umeshkumar Anajwala

Hi Alessandro, Hi Zeno!

According to my experiences, you generally have to distinguish betweem the numerical approaches of the BHE, Al-Khoury and Eskilson/Claesson. But before that, it is crucial to regard different model settings, f.e. such as using a full confined vs. Richards' approach, so each model will have a unique time-stepping behavior. Thus it is only possible to have a 'rule of thumb' - mostly based on user experience - for the stepping.

For the Eskilson/Claesson approach (analytical BHE calculation), my recommendation is:

You may use AB/TR schemes when the flow setup is easy (steady flow, confined or phreatic approach) or switch to FE/BE when dealing with more complicated flow settings directly. Do test runs and test for constraining the time-step by each the growth (typically values between 1.1 and 2) and the max. time-step size (the default 10 may be a good starting point, but I had models put down to 0.5 days). This setup should converge already with the first iteration, so it is acceptable to reduce the number of iterations from 12 to 1. In order to compensate, choose a smaller error criterion of 1e-5.
Before you run the model, create a nodal selection on the BHE or group of BHE's and activate the charting mode for the BC's. When running the model, check the amount of input power over time, vs. the period heat budget of the BHE in the chart. These values should be almost identical. If not, try reducing the time-steps by constraining the step size, or by using a smaller error criterion, or even by using the stricter L1 or max. error norm. When you apply an input of temperature to the BHE's, I would suggest to compare different BHE heat period budgets for different time-stepping sizes. When you run with a smaller time-step and the value does not change anymore, the convergence is fine. This is the identical strategy to running models with different mesh resolution and check for mesh convergence, only the resolution is a temporal one.

For the Al-Khoury (full numerical approach),

I would suggest to directly use a FE/BE scheme. A fine vertical resolution of the model is also crucial. At least 1m for the slice distances, according to my experience. It is not ok to run this with a single iteration, so the number of iterations should be set as default 12. I usually apply a max. error norm, this already ensures a small stepping. Smaller error criterion and constraining time-steps by growth or size are optional, but I would recommend to use a small growth of 1.1 to 1.2 and also a 1e-5 error criterion. Also do test-runs just like with the analytical approach. Since Al-Khoury is used for short period simulations, a max time-step size is hard to estimate, it may be needed to put that even in minutes.

Upwinding schemes: I try to avoid using them if possible, since you cannot control the amount of artificial dispersion which comes into the model. This will affect the physical behaviour of the model, and I would like to keep control of that. Therefore, it is a good idea to control things by the longitudinal/transverse dispersion material parameters instead and improve discretization even before that. When none of these measures help, the upwinding can be a last resort.

I hope these suggestions provide some help in your setups. However, they do only reflect my personal working experiences, so it would be really nice if others share their experiences here as well.

Best regards,

Bastian

When using the in-/outflow on top/bottom or the source/sink material parameter, inflow (recharge) is positive, outflow (ET for example) is negative. When using a Neumann boundary condition (for example in the case of a vertical cross-sectional model), inflow is negative, outflow is positive.

In FEFLOW 6.1, the Period Budget allows the export of all budget components for all time steps. Check the Export checkbox before calculating the period budget (having opened a FEFLOW results file / *.dac). The exported values are written into a *.txt file that you can easily import to Excel, for example.

Last chance to give your opinion - voting closes tomorrow!

FEFLOW Help System:
Reference -> File Formats -> Database -> *.pow

One reason for this could be a snap distance set to something larger than 0. Then also neighboring elements may get the value set for an element, and the time series ID finally found on the neighboring elements will depend on the input order (order of polygons in the file). So when doing polygon import, you should typically set the snap distance to 0.

Dear Forum users,

We're currently preparing the next FEFLOW release. To help us optimize the content of the User Manual, I'd like to get your feedback on this topic. It would be great if you could choose the option that fits best to your use of this source of information. Don't expect that one of them fits perfectly!

Your honest opinion and additional comments are appreciated!

Thanks in advance!
Peter

No, FEFLOW scales in all directions in 'Phreatic' mode. Alternatively, a fully unsaturated model can be used with simplified parameter sets, but the empirical relationship chosen will also be applied in all directions. A directional dependency can only be achieved by inputting anisotropic conductivities.

Just noticed that I had not commented on the number of columns yesterday: There's no limit on the number of columns in FEFLOW. Depending on the format you use, there might be limits in the software you are using to create the files. For example, old versions of Excel only support 256 columns (which used to be quite relevant when working on the dbf tables of shape files in Excel). However, newer versions do not have this limitation (but do no longer allow to save dbf...). To overcome these limits, you can also join several tables in FEFLOW if necessary.

Hello there,

This is my first time using MIKE21 and I'm using it to model flooding in a section of the Fraser River (BC). I haven't ran into any problems yet until the very last step: defining the output file. I get the error of wrong dimension of output file and spent several hours trying to figure out why this is happening. I'll do my best to explain what I've done up until now.

I obtained a .gdb surface model and extracted the xyz coordinates on a 10mx10m using ArcGIS. Using this data I defined the bathymetry on a 35mx35m grid with 194 grid cells in the X-direction and 419 grid cells in the Y-direction. Any cells in the bathymetry data that had no elevation data were filled with "land values". After modifying the bathymetry to my satisfaction I saved the file and began a .m21 file to begin defining the simulation parameters.

Everything went well until I got to the last tab "Results" where I defined a type 2 output file. The program automatically detected the size of my generated grid (194 cells by 419 cells) and number of time steps (72). For some reason I get the error of wrong dimension of output file. I've tried changing the range of the cells for the output but nothing seems to work. I still get the same error for a type 1 output file (line series).

Any suggestions would be appreciated.

Steven