mwtoews

What is your free surface settings? If "fully confined", the well should be able to pump at a constant rate, however if using "unconfined" settings, the well BC can go "dry" and stop pumping. It would be expected to oscillate as the BC turns on/off due to over pumping and recovery.

Do you have your LD_LIBRARY_PATH variable set to include /opt/wasy/lib64 (or wherever you installed FEFLOW?). It looks like you have stuff installed in a mixture of prefixes: /usr/lib64 and /opt/wasy

E.g. with everything stored under the prefix /opt/wasy
[code]
$ LD_LIBRARY_PATH=/opt/wasy/lib64 ldd /opt/wasy/bin/feflow6110q
linux-vdso.so.1 =>  (0x00007ffff13ff000)
libfeflow61.so.6.1 => /opt/wasy/lib64/libfeflow61.so.6.1 (0x00007f8c7e442000)
        ...
$ readelf -Ws /opt/wasy/lib64/libfeflow61.so.6.1 | grep "__kmpc_atomic_fixed8_orb"
  578: 0000000000000000    98 FUNC    GLOBAL DEFAULT  UND __kmpc_atomic_fixed8_orb
[/code]

[b]SOLVED[/b]. I found the correct link flag for the last step: -lXt

Here are the complete steps.

[i]Step 1:[/i] compile libifm from the SDK (this can be done in /opt/wasy/sdk/ifm/src if you have the privileges):
[code]
cd /path/to/wasy/sdk/ifm/src
gcc -fPIC -I../include -I../include/xdk -c *.c
ar rcs ../lib/libifm.a *.o
[/code]

[i]Step 2:[/i] compile the custom IFM Add-In:
[code]
cp /path/to/wasy/sdk/ifm/lib/libifm.a .
g++ -fPIC -I/opt/wasy/sdk/ifm/include -I/opt/wasy/sdk/ifm/include/xdk -c -o HelloWorld.o HelloWorld.cpp
g++ -fPIC -shared HelloWorld.o libifm.a -lXt -o HelloWorld.so
[/code]

Then open FEFLOW, register HelloWorld.so ... works!

I have C++ source for an IFM plugin that I developed with MS Visual C++ 2010 Express which I'd like to use for FEFLOW 6.1 under Linux (CentOS via RPMs) for some batch runs. How can this module be compiled? Here is what I've tried, using the older HelloWorld example from outdated documentation for the Motif interface ([url=http://www.feflow.info/fileadmin/FEFLOW/download/other_docs/ifm_example.pdf]http://www.feflow.info/fileadmin/FEFLOW/download/other_docs/ifm_example.pdf[/url]):

In the directory with the various source files HelloWorld.cpp/.h/.def, here are my shell commands:
[code]
g++ -fPIC -I/opt/wasy/sdk/ifm/include -c -o HelloWorld.o HelloWorld.cpp
g++ -fPIC -shared HelloWorld.o -o HelloWorld.so
[/code]

There are no errors from any of the commands. The problem is that the objects are not linked up, so when I try to register this module in the feflow61q GUI, I can browse to the HellowWorld.so file, but I have a FEFLOW ERROR dialog:
[quote]
Cannot load "/path/to/HelloWorld.so": /path/to/HelloWorld.so: undefined symbol: IfmRegisterModule
[/quote]

Obviously there is some kind of library linking error. Note when I compiled the module, I specified the include directory, but not a library, since I don't know where this is. It was not provided by wasy-feflow_ifm_devel-6.1-10.noarch.rpm, as the /opt/wasy/sdk/ifm/lib directory is empty. What am I missing?

[hr]
[b]Some progress[/b]: It appears that libifm.a can be built somewhat following /opt/wasy/sdk/ifm/src/Imakefile (I don't have imake, or root access, thus I do my work in a different directory with copies of the source files):
[code]
cd /path/to/wasy/sdk/ifm/src
gcc -fPIC -I../include -I../include/xdk -c *.c
ar rcs ../lib/libifm.a *.o
[/code]
Then libifm.a can be copied into the same directory as HelloWorld to recompile with the new bits:
[code]
cp /path/to/wasy/sdk/ifm/lib/libifm.a .
g++ -fPIC -I/opt/wasy/sdk/ifm/include -I/opt/wasy/sdk/ifm/include/xdk -c -o HelloWorld.o HelloWorld.cpp
g++ -fPIC -shared HelloWorld.o libifm.a -o HelloWorld.so
[/code]

And following the same registration procedure as above, I now get an error dialog with "undefined symbol: XtDisplay". I feel like I'm getting closer, but I can't say I know much about the X11 library, nor do I care. I don't require graphics for my objective. Dropping -lX11 in at various places didn't seem to do anything.

Thanks Peter. It looks like a workaround is to get path to the FEM file, and read the MMLIST section into a 2D float32 array with dimensions (ne, n_entries). Tricky, but not the first time I've implemented a reader for this FEM section.

Hi,

I would like to know if there is any IFM interface to get to time dependent material data, such as "IN(+)/OUT(-)FLOW ON TOP/BOTTOM", which can implement time-varying recharge. I am using FEFLOW 6.0 for now.

With a FEFLOW problem that implements time-varying properties
[list]
[li]IfmGetMatFlowSinkSource - returns 0.0 for all elements[/li]
[li]IfmGetMatFlowRechargeValue - returns the correct values for the initial values in (in the ASCII format, under MAT_I_FLOW, 107  0.000000e+00 "In/outflow on top or bottom", ...).[/li]
[/list]

It appears that the time dependent material data is inaccessible from the IFM interface, at least from version 6.0. In the ASCII FEM file format, this data is in the MMLIST section. Is there a current hack for 6.0? Is there an IFM interface for this type of data in 6.1?

Lastly, what's the difference between IfmGetMatFlowSinkSource and IfmGetMatFlowRechargeValue?

Thanks.

Ultimately, I need to do some bulk comparison of landuse/pumping between a baseline and several scenarios. In order to do this, I need to have node-by-node output for each timestep for flow budget, head, etc., but to do this type of analysis, the simulation results need to be processed in some high-level interactive array environment, such as MATLAB, Python (NumPy), R, etc.

Basically, my plug-in saves the full simulation results into a single HDF5 file with several useful 2D datasets (head, boundary_flux, area_flux, etc.) with dimensions (np, numb_dt). After the simulation is complete, I can open the .h5 dataset file anywhere else (e.g. HDF5View, MATLAB, or Python) to process my data and find differences between baseline and each scenario, visualize/map differences, etc.

At this moment, I'm nearly finished my IFM module, and am focusing on populating the .h5 file using the HDF C++ API. The finished IFM plug-in will be similar to my wishlist item: [url=http://www.feflow.info/forum/index.php/topic,961.0.html]http://www.feflow.info/forum/index.php/topic,961.0.html[/url]. (Sorry .. I can't share the full IFM add-in due to work restrictions.)

My solution is to track this independently, using a module global:

[code]
int ts; // time step integer

static void OnEnterSimulator (IfmDocument pDoc)
{
    // Reset time step
    ts = 0;
...

static void PostTimeStep (IfmDocument pDoc)
{
    ts++;
    IfmInfo(pDoc, "Processing timestep %i\n", ts);
...
[/code]

Chris, this is the route I'm now on. I have determined the DAC file does not have any budget info, and has decaying documentation. I discovered two days ago that writing my first IFM plug-in is actually not difficult (and I barely know C++). My working code is something like:

[code]
static void PostTimeStep (IfmDocument pDoc)
...
IfmBool res;
IfmBudget *pBudget = IfmBudgetFlowCreate(pDoc);
IfmBudgetComponents budget;

int np = IfmGetNumberOfNodes(pDoc);
for (int node=0; node < np; node++)
{
res = IfmBudgetComponentsQueryFlowAtNode(pDoc, pBudget, node, &budget);
/* Do something with:
budget.area_flux;
budget.boundary_flux;
budget.total_flux; */
}
// Free memeory
IfmBudgetClose(pDoc, pBudget);
...
[/code]

Simple question. I'd like to get the current time step integer. I've tried [tt]IfmGetAbsoluteSimulationTime[/tt], however, this is not quite the same (it is a floating-point day, not an integer for the time step). Please help me fill in the blank, or prove me a way to determine the time step.

[code]
static void PostTimeStep (IfmDocument pDoc)
{
double abs_sim_time = IfmGetAbsoluteSimulationTime(pDoc);
        int ts_num = ??????;

IfmInfo(pDoc, "At timestep #%i, with absolute time %g days\n", ts_num, abs_sim_time);
}
[/code]

Thanks!