Peter Schätzl Grundwassermodellierer

Yes, you are right. FEFLOW assumes air to be perfectly non-conductive and without capacity, thus the terms "solid" and "fluid" for the two phases with thermal conductivity/capacity.

WRT Bug 2: If you set observation points on slices in a free & movable model, they can be moved with the slices, even well below the water table. Use XYZ observation points to avoid this.

Extremely high contrasts in conductivity such as the ones introduced by a multi-layer well in low-k material create some difficultiy for the solver. First of all, please check whether you are using SAMG, and - if yes - what the internal error criterion is. This should be small, e.g., 1e-12. Otherwise SAMG may terminate the iteration too quickly, producing somewhat random results. Then, make sure time steps are small during cone development. In case of time-dependent abstraction, smooth changes in rate may also help.

In a homogeneous material such as concrete, I'd expect dispersivity for heat transport to be small. If you think about heat plumes from open-loop geothermal installations, however, that move in a heterogeneous aquifer, I would put higher values. Note that there is a dependency between the length scale of the transport phenomenon and dispersivity, outlined for example in https://www3.epa.gov/ceampubl/learn2model/part-two/onsite/longdisp.html.

I think you can introduce gaps by setting nan values to a certain time (not a number), but I've never tried.

1) Yes, using this configuration at nodes outside the currently flooded area (and with hh in gw lower than river water level) you will still get infiltration. The only way to limit the area in this case would be to use different time series on all nodes, depending on the time they are flooded. This is not easy to set up and hard to maintain for different scenarios for river levels.

2) Yes, this can be done at least in the last few FEFLOW releases, and it is definitely the preferred option. In one or two older versions, though, (maybe 6.x or 7.0, not sure) FEFLOW will reverse the flow in case that the river water level (transfer bc value) is LOWER than the river bed elevation (head constraint) as the differential between water level and constraint becomes negative. In even older versions FEFLOW will ignore the constraint in this case, hereby possibly creating way too much inflow from the river where none should occur. So if you're not using 7.2 or 7.3, please check with a simple test example.

3) I guess you could (as far as I know it supports limiting the BC area to the flooded area), but the main reason for using this is normally the need for keeping a balance within the lake / river.

Transient material data such as recharge cannot be set via the programming interface.

User data distributions only hold scalar data, there is not option to store vector data.

Yes, having saved a dac file from a 3D simulation, you can use Save as... and save a cross-sectional file.

1) You need to load the DAC file.