• Re: error in simlation of density dependent flow

    to find an element you can go to the mesh generator menu and browse the mesh with the enlarge button.

    otherwise, export is to *.shp file and browse it with GIS program.

    to define exact element type u can use the built-in option in the generator menu and decide number of elements. for example if you have a 1200m line and you wish a 40m element type 30 (i.e. 1200m divide to 30 elements give 40m to each element).

    Elad :)
  • Re: merging 2 dac files

    If I understand the question, you have a model initially set up to simulate from time = 0 to time = 10 (for example). However, you stop it at time = 6 to take a look at results. Now, you wish to restart it so that the simulation may continue to time = 10.

    Situation 1. You have only "paused" the simulation. Analysis can proceed for the current time step only. Click on "(Re-) run simulator " to restart the simulation from where you left off. The dac file will be appended.

    Situation 2. You have stopped the simulation and either (A) selected Exit to Master Menu ... Postprocessor ... and opened the dac file, or (B) closed FEFLOW ... restarted FEFLOW ... Postprocessor ... and opend the dac file. Opening the dac file in the postprocessor allows you to analyze any time step completed by the model. In this case, if you wish to continue the simulation, click on "Continue Simulation". The program opens a new menu from which you can change output options, solver options, and start the simulation. The new simulation results will be appended onto the existing dac file (indeed, it appears that this cannot be changed, if the initial simulation wrote to a particular dac file, so must the continuation).

    I have run into situation 2 frequently. For example, if the power goes off during a simulation. To recover, I just open the dac file, and click on "continue simulation". A very nice feature not found in the MODFLOW GUIs! Be carefull however. Stopping and restarting in this way actually writes model results for the last time step completed. This time step will probably not be a time step for which you have specified to save model results (if desired under "Saving time levels at fixed stages as edited").

    Situation 3. Your model has finished to t = 10. Upon opening the dac file, you still have the option of continuing the simulation only you must specify a new final time (default appears to by a final time equal to the original file time plus the original model duration, i.e. t = 20 in my example). The results will be appended to the existing dac file (again, it cannot be changed).

    I am not clear on what you mean "running it as a batch file" and this may have some bearing on my answers. However, I agree with Chris--Why would you need to merge them (outside of the FEFLOW environment). Strictly speaking, the dac file can be saved as a text-file, and through some careful editing, one could merge two dac files together, but it seems to me that there is an element of fraud involved. The merged dac file may not truely represent a valid simulation.
  • Re: merging 2 dac files

    Interesting question! I'm not aware of such an option. Why would you need to merge them though?

    Chris
  • Re: tracking travelling times and porosity


    I have a whole collection of those small, simple models. I use them mostly for debugging IFM modules, but they help a lot understanding how parameters work as well.

    Good luck with your particle tracking,

    Chris
  • Re: tracking travelling times and porosity

    Hi Chris,

    thanks for your support... It's a real good idea to keep small examples models at hand so that you can check out the effect of modifying a parameter on the modelling results.

    bye!

    Thomas

  • Re: tracking travelling times and porosity


    Hey Thomas,

    I was going to say the default value for porosity is 0.3, but I'm not sure any more. I used one of my small examples and ran particles with the default settings, then set the porosity explicitly under "SET" to 0.3 (and 0.6 / 0.15). A porosity of 0.3 returned very similar results, but not quite the same. You might wanna try this yourself ... I'd say 0.3 is a close enough assumption though.

    Cheers, Chris
  • tracking travelling times and porosity

    Hello everyone,

    I'm using the 3D particle tracking of FEFLOW (in 3D Options -> Pathlines).

    I would like to know what FEFLOW uses as a default porosity value to calculate the travel times.

    I know you can specify values for porosity and sorption if you go in the ''SET'' menu related to ''USE ISOCHRON MARKERS''.

    However, when I'm not using the isochron markers, I can't figure out what FEFLOW uses as a porosity value to calculate the travel times? This is a problem for me since I exported many tracking results as .DAT files and I'm not sure about the validity of the travel times I obtained.

    Note that I'm running a 3D [u]saturated [/u]model and [u]solving for flow only[/u].

    Any help appreciated!
    Thanks!
  • Re: Depth-dependant Evaporation

    Hey Andrés,

    I assume your model would be transient and the water table somewhat "well behaved", meaning there is only one (no perched system with more than one free water table at different elevations).

    Between time steps, you would have to find that water table, calculate the depth from GS to water table, and then set the boundary condition according to your equation?? The boundary condition would then be assumed to be constant for the next time step. Are parameters A and B constant or variabel over time? They would have to come from an external data source (text file, DB). Is that would you were thinking?

    If your FEM isn't too too large, would you mind emailing me a version?

    Thanks, Chris
  • Re: error in simlation of density dependent flow

    Dear chrisoula,

    it is typical for density dependend problems that stability problems occur. To handle this, you have to refine the grid in all 3 directions. Additional a wise time-stepping is necessary. Furtheron you could try upwinding settings.
    In my opinion, you should check this first, before you try to find and modify just one element.

    Kind regards,
    Wolfram


  • Re: IfmBudgetComponents - area flux

    1) From what I understand, the elemental recharge gets aggregated to the nodes based on some sort of "area of influence" (likely a Thiessen polygon). That's ok in general, but introduces a small error to sub-watershed water budgets. Nodes right on the sub-watershed boundary add recharge from the neighbouring elements outside the current sub-watershed! To verify this, compare the sum of recharge of all individual sub-watersheds with the total recharge of the model. The same issue applies to all other BCs on a polygon boundary (luckily, rivers and lakes rarely fall onto a sub-watershed boundary ;D)

    2) I had to think about this one for a moment, but it does make sense. If you look at the file documentation (file_formats.pdf), a DAC file is basically the FEM file plus the model results. For a transient run this would be
    Ini Cond (as in FEM file) plus
    Results TS 1
    Results TS 2
    Results TS 3
    etc ....

    For individual TimeSteps, only the results get exported, but not the other model parameters. This is a good thing though, since the DAC file would get really really big for a transient run otherwise. Since you are already working with IFMs, Peter's suggestion is the way to go! Two more thoughts on that:

    a) The API function for calculating the flow components (IfmBudgetComponentsQueryFlowAtNode) are SLOW! I normally call them only for nodes that actually have a BC, and avoid the call for nodes with no BCs. The check
    IfmGetBcFlowType(pDoc, node) != IfmBC_NO
    takes computational time as well, but likely less then IfmBudgetComponentsQueryFlowAtNode. You might wanna check this in your particular situation.

    b) Using an IFM module gives you the chance to calculate the recharge to an area more precisely than the water budget functions. Rather than using nodal recharge values, you can use:
    elementalRecharge = elementArea * IfmGetMatFlowRechargeValue(pDoc, element)
    This overcomes the issue mentioned above (see 1), however, you need to calculate the element area "by hand", since there is no API function available for this (if there is, it's not documented at least)

    Fun stuff, Chris