amelia

I accidently deleted an element in the middle of my mesh.  Now I have a hole the size of one element.  How can I reinsert that element without reverting back to an older model?

the unit in the keyboard request box in my version is 10-4/d,  not 10-4 m/d.

Upon more more investigation I realized not only are my .dac files takinga a LONG time to open they are not including the entire run.  Even though the .dac file was being updated every few minutes throughout the run and resulted in a large .dac, only the first 99 iterations were in the .dac file that I opened.  It seems like something is not being written appropriately in the .dac file.  Any ideas?

Recently I added an additional layer to a model  that I was having some oscillations in.  The vertical refinement helped with the oscillations, but my run times increased significanly.  But more troubling is the .dac files are know taking 15 to 20 minutes to open previously they took about 1 minute.  The size of the files has not increased 15 to 20 times.  Does anyone know why this may be occuring?

When using the budget analyzer to determine flux through inner and outer boundaries within a polygon segment  the model returns different values depending on the zoom extent.

This is very disturbing to me  since nothing is changed other than the zoom.  Is the value determined with the zoom set to the full model extent reliable?

I regualrly import shapefiles with nodal or elemantal data to adjust  K distribution or starting head distribution.

Recently for some reason I can no longer seem to properly import a shapefiile using the Assign - Database - regionalization method?

When attempting to do this FEFLOW slowly acts like it is importing the data, but the values which the model is populated with are totally wrong.

I was successful in exporting a triplet (.trp) file from the output of one model and importing it as the starting heads for a subsequent model.  So it seems the problem is with the file format rather than the regionalization.

With this in mind I tried to turn a shapefile with K distribution into a .trp file using the method described in a previos post by Vlad.  However when I imported the newly made .trp file a warning came up stating " Line 1: Invalid Coordinat Format". 

At this point I checked the .trp files that were directly exported from  the model verses the one created from the shapefile and discovered the x and Y values were completely different????

[u]Do the .trp files utilize the origin set up for the model or are they (0,0) at the origin[/u]?

[u]Also is there any explanation for shapefiles to no longter be read properly by Feflow?[/u]

I have been running a rather large model in Steady State and not achiving convergence. I am using the default convergence criterion (Euclidian error norm 1 x10-3).  My model has dramatic topography and dramatic water table topography ranging from 600m to 2200m.  At these elevations the error criterion seems especially large so I do not want to increase the criterion.

The model is 6 slices and has several drainages simulated with Transfer boundaries.  The mesh is highly refined around the boundaries.  There is not dramatic hydraulic conductivity zonation.

I have used both PCG and SAMG  both fail to coverge but SAMG gives bizzare head results whereas PCG produces realistic heads and has a very low mass balance error.

I have since run this model in quasi steady state (long term transient) with reference observation points.  During the quasi steady state run  i noticed a few of the reference observation points oscillated several meters during the simulation.    The oscillation i believe indicates the model has instability at that location. 

I am wondering if there is a FEFLOW running file that keeps track of nodes in the model that have the greatest error during each iteration.  Or some otherway to locate problem areas within the model.

[b]After downloading the latest patch, femathed10.dll will no longer load but it is still in Bin32 of the Feflow program files???

Please notify me on how to allow Feflow to run with the problem editor properly loading.

Thank you[/b]

My Steady State Model has a high mass balance error (7%) however a long term transient run of the same model with no changes to stresses has a low mass balance error (0.1%).  I am trying to resolve why the Pseudo Steady State model has such different mass balance error.  I am using the deformable mesh surface definition (top layer free and movable).  Are there problems with trying to reproduce the same results with a steady state and a pseudo steady state when using the deformable mesh?  Moreover, is the Pseudo Steady State Mass Balance error more representative or less representative of the models computational accuracy than the SS mass balance error? 

Is there a way to view areas/nodes where error is occuring within the model, i.e., the nodes with the greatest head change in successivive iterations?