This would be a great idea. I think modifying the posted FEWarp source code would be even better than just updating the binaries, though. Something about the lines below does not work quite the same with FEBio v2.6.4 (at least on 2.6.4.9499).

FEModel& fem = *GetFEModel();
FEMesh& mesh = fem.GetMesh();

Cheers,

Dave.

Hi Dave,

Is this still an issue for you?

Thanks,

Steve

Hi Steve,

Yes. I was actually working on this to test the 16-bit support in FEBIO 2.7. If it helps at all, FEBIO 2.7.9579 returns a segmentation fault early on, FEWarpConstraint.ccp lines 48 and 49--the reference "el" (FESolidElement&) does not seem to be valid, so things go bonkers when trying to evaluate el.GaussPoints(). <sigh>

Cheers,


Dave.

Okay, let me look into it today.

Steve

PS: our forum is about to go offline for a couple of days for some maintenance, but I'll get back to you as soon as I can.

Hi Dave,

It turns out we haven't uploaded the warping plugin for FEBio 2.7. I apologize for that, I thought we had that taken care of. I will upload our latest version as soon as possible, but I'm not sure if I can get it done today. Would it help if I send you our latest source code?

Cheers,

Steve

Dave,

Are you building your own plugin or are you using the dll file in the zip file from the website? I suspect the former since that dll will not even run with FEBio 2.7. But the odd thing is that the source code is still fully compatible with 2.7. I just tried it and it seems to work fine for me. So if you are building your own plugin, I'm not sure why you are running into problems. Can you tell me anything else that might be helpful in resolving this?

Thanks,

Steve

Steve,

I am indeed building my own plugin on Fedora 27. I dowloaded the source this morning (no mods), and set include and library paths to the FEBio 2.7 sdk. It compiles via gcc (config below) with no errors or warnings. All problems occur at run time, and seem to be related to a reference that I mentioned earlier.

I have been trying to alter the source, but if the code is fully compatible with 2.7 as you point out, then maybe (?) it is time to focus my efforts on the make recipe.

Not sure if that helps, but thanks for looking into this.


David.



[dgomez@dogleg]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)

Oh, this is on Linux. In that case, I'll have to ask Dave Rawlins to look into this.

Are you building the FEBio code too? If so, I do recall that you have to make sure that you are linking the c-runtime library as a shared object, not statically. I'm not sure how to do this on Linux though. Hopefully, Dave R. can provide some insight. The reason this is important is because dynamic_casts are not guaranteed to work across a dll interface when the dll and the exe are linked to separate c-runtime libraries (which would be the case if both link statically). One thing to try, is to replace the dynamic_casts in the warp plugin code with static_cast. A static_cast should work across the dll interface. Of course, you will have to make sure that the cast always succeeds (by only having solid domains in your model), otherwise the plugin may still crash. Let me know if that worked.

Cheers,

Steve

Not building FEBio code. I am pretty sure I am linking as a shared object. It seems that the dynamic cast was not the issue, since the FESolidDomain reference does allow me to evaluate Elements(), which I assume won't work if the cast was not correct. In any case, changing to a static cast still returned what appears to be a bad reference to a FESolidElement, causing the (run time) Segmentation fault when evaluating GaussPoints()--no luck.

Since I am using the precompiled version of FEBio 2.7, which was built using a "new" glibc, it may be (frustratingly) possible that things will work with a FEBio 2.7 build using the old "centos" one. However, that is not available on febio.org yet, so I can't try it for now.

I look forward to hear from Dave R.

Thanks,

Dave.

Thanks for the feedback. I agree that at this point an incompatible glibc is most likely the culprit. Let's see what Dave R. says.

Steve

An update: I successfully compiled the hyperelastic warping plugin using the FEBio 2.8.0 SDK in linux (Fedora 27). But, when using the precompiled binaries from febio.org, the plugin failed on run time due to a segmentation error. This was the case when using both versions of glibc. In addition to this, I successfully compiled FEBio 2.8.0 on my system, but a run-time error appeared when trying the plugin (also compiled on my system). In particular,

Success loading plugin libFEWarpImageConstraint_gcc.so (version 0.0.0)
Reading file test1.feb ...FAILED!
FATAL ERROR: invalid value "warp-image" for attribute "constraint.type" (line 14641)

Which is odd, since it suggest that the plugin has been recognized, but it acts as it was not. BTW, the code runs when I remove the call to the image constraint and its plot output (but, of course, nothing happens).

Any ideas are welcome.

Thanks,

Dave.

Hi Dave,

Thanks for the update.

For what it is worth, I remember that the main issue we had with Linux plugins was with the c runtime library. FEBio requires that both the FEBio executable and the plugin use the same shared library version of the c runtime library, otherwise odd things can happen.

Our busy summer schedule is winding down, so I plan to take a look at this myself soon. I'll keep you updated.

Cheers,

Steve

Cheers,

Steve

Sorry, but this is likely not the right location for this problem but I needed to start somewhere. Am trying to run warping with contact. The problem runs fine without contact but once added into either febio2.51 and febio2.9, they crash. Contact alone runs fine. Once I add the constraint section it crashes.

Alex

Hi Alex,

Can you please send us some example files so that we can replicate the issue on our end? If they are too big to upload here, you may send them to steve dot maas at Utah dot edu.

Thanks,

Steve