Please wait...
×

Error

  • Re: Problem with hydraulic head BC with constraint

    [quote author=Peter Schätzl link=topic=20562.msg26503#msg26503 date=1498196102]
    Hi,
    in steady-state the correct working of constraints ist not strictly guaranteed. They are evaluated once and then kept, as otherwise the model would very likely loop infinitely over finding the correct status. In such a case, where the spring BCs keep infiltrating water, I recommend to run the model in transient for a while. Once the correct water table is found, it might work to run scenarios in steady-state again (assuming that the conditions at the springs do not change much).
    [/quote]
    Dear Peter,
    are you sure the constraints are only checked once? The calculation time of my current model (steady state using boundary condition constraints) seems to be multiple times slower than the calculation time of a model without bcc. I would expect, that in the case descibed above calculation time should max. double. Furthermore Feflow displays the attached message (reprofiled matrix at time 0.001).
    Greetings
  • Re: Coupling Feflow and Phreeqc

    I'm very interested in the phreeqC plugin. Is there any progress?
    I know there is a beta-Version of a plugin, is it possible to try it?
  • Re: Gas exsolution

    It does not make sense to link a timeseries to a material property, if you want to modify the timeseries while simulating. The link between timeseries and a material property is set once and feflow writes the whole data into the model files (this works only for BCs etc.). A modification of the timeseries afterwards does not effect the material property.

    you could write a plugin, using the functions:
    IfmGetResultsFlowPressureValueAtXYZ
    calculation of Gas exsolution
    IfmSetMatFlowStorativity

  • Re: Is it possible to create a .fem file from a .dac file?

    Does it allways work, or are there any situations, were one has to be carefull?
    We were simulating a flow&transport model in an unconfined aquifer and I remember (rather sketchy), that we experienced some mass instationarity if we created a fem-file from a dac-file (we chose a timestep in the middle).
  • Re: FEFLOW 6.1_Groundwater recharge input

    @Lamm
    Yes, 30 different timeseries for corresponding 30 polygons.
    The Feflow 6.1 Help offers the chapter workflow. one of the features is "Assignment of Time-Varying Material Properties". There you'll find the method offered "Join Time Series to Maps". It is possible to join timeseries (pow data) to polygons (shape). In the end it worked, as well as following budget analysis. There seems to be no limitation (<20years).

    @Peter
    I'm quite sure that i used a snap distance of 0. (I remember even trying -1). I still hope that Feflow 6.2 offers a method which uses the timeseries editor (like boundary conditions, wells etc.).
    I attached two screenshots. The colors correspond to areas of the same groundwater recharge. Colour values are different in both screenshots, they only should cover the same elements. As one can see, there are allways some with wrong values.
    You don't have to go into detail, if it's not a known issue. I only wanted to say: Be careful.
  • Re: FEFLOW 6.1_Groundwater recharge input

    I experienced some problems by using the method "Use Map Data: Join Time Series to Maps" (which would be the method of joice in the above case, i suppose).

    I had 20 years of groundwater recharge daily values and about 30 different timeseries.

    1) I exported the elements (ca 100000) of the first slice and assigned each element one of the 30 timeseries nr in ArcGIS.
    2) Then I used the method above, but there were allways some elements with wrong timeseries.

    Only by repeating these steps (1+2) for elements with the wrong timeseries, I could solve the problem. In addition this is a very slow process. It didn't help to merge elements in the element shape with the same timeseries.

    It is also impossible to export the assigned timeseries (possibly because of the huge amount of data).

    My workaround was to analyse and write directly into the ascii-fem file with python.