System call from fortran . . .

I used Netgen successfully in 2013, using system calls from fortran code.

I am trying to use it again. I installed the package on ubuntu 16.04 using the installers. I verified the install by using the GUI to mesh a few of the supplied geo files. (I have since since upgraded to ubuntu 17.04).

My old codes/scripts don’t work for command line execution (system calls). I can get netgen to read files and create output files - at least .vol and .mesh (neutral) files. But no meshing occurs.

For example, one of the commands I tried is (with out.vol being a .vol file generated by netgen):
netgen -batchmode -inputmeshfile=out.vol -meshfile=new_out.mesh -meshfiletype=“Neutral Format”

No luck.

This (no meshing) also occurs when trying use the GUI to mesh the .vol file. Nothing happens. The input object appears, but attempts to mesh (by pressing Generate Mesh) doesn’t do anything.

Any pointers?

Side note: I got a note saying that I should make sure ng.tcl is in NETGENDIR: Should that be ngsolve.tcl? I don’t have a ng.tcl on my system.

Thanks in advance,
Tim

exporting mesh files from command line is working again, it will be available in the nightly build and source tree.

thanks for the report.

best, Joachim

Thank you for the quick response.

Unfortunately, I used the “Installer” approach described on “ngsolve.org” to install ngsolve, and the “hint” about how to get to nightly builds didn’t lead me anywhere.

Fortunately, I noticed (in a sidebar on SourceForge) that Matthias Hochsteger (?) posted a “how-to” wrt getting nightly builds.

I followed his instructions in an attempt to get the nightly build: The version I am using is 6.2.1707, and I don’t know if that is a nightly build.

In any case; the command:
netgen -batchmode /usr/share/netgen/cube.geo -meshfile=cube.mesh -meshfiletype=“Neutral Format”

results in a meshed cube. Though when I try to import cube.mesh into netgen (gui), it crashes.

The command:
netgen -batchmode /usr/share/netgen/cube.geo -meshfile=cube.vol

results in a file that can be read into netgen (gui). (Though it has a couple of suspicious-looking entries - huge negative integers.)

The command:
netgen -batchmode -inputmeshfile=example.mesh -meshfile=output.vol

passes through the info, but no meshing occurs.

The command:
netgen -batchmode -inputmeshfile=example.mesh -meshfile=output.mesh -meshfiletype=“Neutral Format”

crashes as it reports:
NETGEN-6.2-dev
Developed by Joachim Schoeberl at
2010-xxxx Vienna University of Technology
2006-2010 RWTH Aachen University
1996-2006 Johannes Kepler University Linz
Including OpenCascade geometry kernel
optfile ./ng.opt does not exist - using default values
togl-version : 2
no OpenGL
OCC module loaded
import mesh from example.mesh
Read User File
Reading Neutral Format
8 Points, 0 Elements.
Export mesh to file output.mesh… Please Wait!
Segmentation fault (core dumped)

Note that example.mesh is:
8
0.0 0.0 0.0
1.0 0.0 0.0
1.0 1.0 0.0
0.0 1.0 0.0
0.0 0.0 1.0
1.0 0.0 1.0
1.0 1.0 1.0
0.0 1.0 1.0
0
12
1 1 2 5
1 5 2 6
1 2 3 6
1 6 3 7
1 3 4 7
1 7 4 8
1 4 1 8
1 8 1 5
1 5 6 8
1 6 7 8
1 1 4 3
1 3 2 1

So, I am still not able to have netgen read a .mesh or .vol file and mesh it.

Thank you for any further guidance:
Tim

I wonder if something could have recently broken with the upstream process for the source tree. The last commit shown at the sourceforge git repository is from 7/18. That seems unusual…

ddrake:

Sorry, I don’t know what you mean . . . BUT:

I did notice that I omitted an (perhaps) important item in my last post:

After I determined that the info on ngsolver.org wrt getting nightly builds (after using a downloaded installer) wasn’t going to help, I decided to install from source. On two ubuntu 17.04 vms.

So, I removed (‘sudo apt-get purge ngsolve’ and ‘sudo apt-get purge netgen’).
I followed the relevant guidelines on ngsolve.org, and both installs got far enough to create netgen, but blew up (in different ways) before creating ngsolve. As I really want to see if netgen will work for me, that is good.

I posted my experiences wrt the above installs on sourceforge.net:
/sourceforge.net/p/netgen-mesher/discussion/905307/thread/05581c49/?limit=25#6e5b

If you would like, I will try copy/paste that here as well. (I don’t really know the protocols.)

One question I have: How would I know if I am getting a nightly build (as described by Matthias Hoctsteger on sourceforge.net)? I have never used nightly builds of a code, but it may be needed to get netgen working for me.

Thank you,
Tim

I have been building from source fairly often on my Linux Mint 18.1 (essentially Ubuntu 16.04) machine. The installation procedure here has been working very well for me. This procedure pulls the latest source code from the git repository at Sourceforge. I haven’t tried installing the nightly builds, but I think the Ubuntu installation instructions here should work. It mentions:

[quote]Every time you upgrade your packages using sudo apt-get upgrade, NGSolve will be upgraded too.
You can also install the nightly build by installing the package ngsolve_nightly.
[/quote]
I believe the main code repository is a private GitLab site which is accessible only to the core developers. Normally, when a developer makes a commit to the master branch of the primary repository, it appears at the Sourceforge site within a few hours (that’s what I meant by the upstream process).

But no new commits have appeared at the Sourceforge site in the past 11 days. In my experience, that is an unusually long time, since the application is actively being developed. I’m not sure whether the delay in pushing commits to Sourceforge is intentional on the part of the core team or if perhaps some automated process has broken, preventing that synchronization. I’m not sure if the nightly builds are based on the code at Sourceforge or at the primary repository.

I think it may be possible that the fix for exporting from the command line mentioned by joachim (Dr. Schoeberl) may not have made it to the Sourceforge repository, hence why it is still not working for you.

Best,
Dow Drake

the public repository is now moved to github, see the ‘downloads’ page, and the docu (nightly version).
Joachim

Dow:

Thanks for your informative feedback.

It is that paragraph which you extracted from ngsolve.org (relative to ngsolve_nightly) that I found ‘frustrating’: When I tried to install the package, it was not found.

But, when I just tried again . . . it was found, but other issues are apparent:

tscale@tscale-mbp-ubuntu:~$ sudo apt-get install ngsolve_nightly
[sudo] password for tscale:
Reading package lists… Done
Building dependency tree
Reading state information… Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
ngsolve_nightly : Depends: libsuitesparse but it is not installable
E: Unable to correct problems, you have held broken packages.

Joachim: Thank you. I will try to install from the source to which you just pointed. Tim

I plan to post a couple of summaries over the next hour or so:

First I reinstalled from source on the two 17.04 vms mentioned in previous posts, following the instructions on the “docu” page on ngsolve.org, except I replaced:

git clone git://git.code.sf.net/p/ngsolve/git ngsolve-src

with
git clone GitHub - NGSolve/ngsolve: Netgen/NGSolve is a high performance multiphysics finite element software. It is widely used to analyze models from solid mechanics, fluid dynamics and electromagnetics. Due to its flexible Python interface new physical equations and solution algorithms can be implemented easily. ngsolve-src

per Joachim’s post. As before, netgen was installed; not ngsolve - on both vms.

In short, I can read/process geo files, though the output file cannot be read/processed. So, I cannot read and mesh “mesh files”:

The terminal exchange for processing a geo file is:

netgen -batchmode -geofile=cube.geo
NETGEN-6.2-dev
Developed by Joachim Schoeberl at
2010-xxxx Vienna University of Technology
2006-2010 RWTH Aachen University
1996-2006 Johannes Kepler University Linz
optfile ./ng.opt does not exist - using default values
togl-version : 2
no OpenGL
Load CSG geometry file cube.geo
Calc Triangle Approximation
Object 0 has 1076 triangles
Start Findpoints
Analyze spec points
Find edges
Start Findpoints
Analyze spec points
Find edges
Start Findpoints
Analyze spec points
Find edges
Surface 1 / 6
Optimize Surface
Surface 2 / 6
Optimize Surface
Surface 3 / 6
Optimize Surface
Surface 4 / 6
Optimize Surface
Surface 5 / 6
Optimize Surface
Surface 6 / 6
Optimize Surface

Meshing subdomain 1 of 1
Delaunay meshing
start tetmeshing
Success !
9 points, 11 elements
Remove Illegal Elements
Volume Optimization
Meshing done, time = 0.024819 sec
Save mesh to file out.mesh… Please Wait!
Save mesh to file … DONE!

Unfortunately, 
 netgen -batchmode -inputmeshfile=out.mesh -meshfile=out_2.mesh

results in an "empty file" - no points, etc..

I note that there are a couple of suspicious numbers in out.mesh. (From the first command.) The relevant section of the file is:

# surfid  0   p1   p2   trignum1    trignum2   domin/surfnr1    domout/surfnr2   ednr1   dist1   ednr2   dist2 
edgesegmentsgi2
24
       1       0       1       4 546802052        1        1        3        1            0        0            0
       2       0       4       1 546802052        1        1        3        1            0        0            0
       3       0       8       7        0        7        5        6        2            0        0            0

Regards,
Tim

I get basically the same results when I execute those commands.

I don’t think the problem is with the first file generated. If I rename it to out.mesh.vol and load it in the Netgen GUI, I see a valid mesh on the cube. The large positive and negative numbers correspond to trignum1 and trignum2. I’m not sure what these mean, but they are large like this in most mesh files I’ve looked at.

I don’t understand why ngsolve is not building from source for you. I was able to build the current source by cloning from github last night. What errors did you get when trying to make ngsolve this time?

Some progress.

I can read/process cube.geo, and if I specify the output filename as cube.vol:

netgen -batchmode -geofile=cube.geo -meshfile=cube.vol

I get a file that can be read by netgen:

netgen -batchmode -inputmeshfile=cube.vol -meshfiletype=“Neutral Format” -meshfile=cube.mesh

Which is not any more meshed than cube.vol.
The resulting cube.mesh cannot be imported (gui). And

netgen -batchmode -inputmeshfile=cube.mesh -meshfiletype=“Neutral Format” -meshfile=cube_2.mesh

results in a bad mesh file (huge integers in the nodal bc info - col. 1 of the last section).

So '.geo' to '.vol' works - and I can get it to mesh, using a sizing flag:

netgen -batchmode -geofile=cube.geo -meshfile=cube.vol -fine

But '.vol' to '.mesh' (Neutral Format) apparently just translates. No meshing. 

Use of '.mesh' files is not feasible.

Regards,
Tim

Dow:

Were you responding to my reply/post that started with “Some progress.”?

I ask because - though your post shows up ahead of that post of mine, it seems quite appropriate to that one.

In any case, I will reply to this post of yours in a “reply” after my reference post.

Tim

Dow:

In response to your question: “What errors did you get when trying to make ngsolve this time?”

I include, “in line”, the two posts I made to a discussion on SourceForge, on this very topic (started by another Tim who had the same issue with BLAS and LAPACK not being found during installation.) Those 2 posts are still valid, as far as I can tell. That is, the (two) installations on the two vms ended the same way in each case.

Let me know if you need something different.

Regards,
Tim

Posts on SourceForge

Post 1, replying to Matthias Hochsteger:

I saw this back and forth a little earlier today. I think I have a relevant observation.
I tried installing netgen/ngsolve on two different ubuntu 17.04 machines today - both are vm's; one fusion and one vbox. Both are on the same MacBook Pro. They both have essentially the same paths (.bashrc) if that matters. I followed the instructions on ngsolve.org in my attempts to install netgen and ngsolve "from source".
In the case of my "main machine", -DUSE_LAPACK=ON in CMakeCache.txt, and neither LAPACK, nor BLAS were found. It did make it through builing/installing netgen, which is my immediate interest.
I just confirmed that -DUSE_LAPACK=ON in CMakeCache.txt on my "side-machine" as well. BUT LAPACK and BLAS were FOUND, and netgen was built/installed. Problems arose during compiling cpp codes. Those problems did not arise on the other machine, but perhaps that is just because the install on my 'side-machine" made it further in cmake/make. (I would need to check, and I don't think that is central to this discussion.)
So, perhaps it is not in the -DUSE_LAPACK=ON setting. Note that the text in CMakeCache.txt files, above the NETGEN_CMAKE_ARGS sections, involve a lot of "info" about both LAPACK and BLAS. I plan to compare the two CMakeCache.txt files.

Post 2, adding more info:

I compared CMakeCache.txt between the two “installations” discussed in my earlier reply.
The two files are very different, and it brought forward at least two things:
I don’t really know how cmake works (and hope to never have to really know).
When I got messages that informed me that LAPACK was not found (upon executing cmake), I was told to specify a lib location - where LAPACK could be found. Perhaps CMakeCache.txt is the file to edit?

Hi Tim,

Sorry – I forgot you said you posted to the SourceForge site. It sounds to me like you may be missing some required libraries on your virtual machines. Did you run this line from the “Build on Linux” page?

sudo apt-get update && sudo apt-get -y install python3 libpython3-dev libxmu-dev tk-dev tcl-dev cmake git g++ libglu1-mesa-dev liblapacke-dev

It sounds to me like you may be missing liblapacke-dev and libblas-dev

To see what libraries you have installed, you can run dpkg --get-selections

Best,
Dow

Dow:

I did run the ‘apt-get update && apt-get -y install …’ command in the installation recipe. I actually have done it before each time I have installed.

I located several locations for both liblapack and libblas, when trying to determine the issue wrt “cmake” not finding them. So, I know they are present, but I didn’t realize there may be a connection to dpkg.

So, I followed your counsel and ran:
tscale@tscale-mbp-ubuntu:~ dpkg --get-selections | grep liblapack liblapack-dev install liblapack3 install liblapacke install liblapacke-dev install tscale@tscale-mbp-ubuntu:~ dpkg --get-selections | grep libblas
libblas-common install
libblas-dev install
libblas3 install
libblasr:amd64 install

Does this help?

BTW: It does not reflect the extensive list I get in response to:

sudo find / -name liblapack*

but that might be expected.

Regards,
Tim

Hi Tim,

Thanks for the info – I was hoping it was something simple. I’ll try setting up an Ubuntu 17.04 VM and see if I can reproduce the issue with NGSolve install.

Best,
Dow

Roger that.

Hi,

regarding the installation issues, the nightly builds should work again. We had some problems with the suitesparse package which is used for UMFPACK. The installation is described in the Downloads section and I just tested it on Ubunut 16.04 using these lines.

sudo apt-add-repository universe
sudo apt-add-repository "deb http://ngsolve.org/files/ubuntu `lsb_release -sc`_`dpkg --print-architecture`/"
sudo apt-get update
sudo apt-get install ngsolve_nightly

[quote]
The large positive and negative numbers correspond to trignum1 and trignum2. I'm not sure what these mean, but they are large like this in most mesh files I've looked at.
[/quote]
The trignum's are used for meshing STL geometries. Therefore you don't have to worry about them when using CSG geometries.

Regarding the mesh file types:
Our standard file type is “.vol” or the compressed version “.vol.gz”. These mesh files can also store geometry data when you mesh a CSG geometry (check the end of the file). This is useful if you want to curve the mesh when you solve a problem with NGSolve.
If you still want to have a mesh in “Neutral Format” you can generate that in one line:

netgen -batchmode -geofile=cube.geo -meshfile=cube.mesh -meshfiletype="Neutral Format"

To check if cmake found any BLAS/LAPACK libraries you could use "ccmake". You have to install
[code]sudo apt-get install cmake-curses-gui[/code]
After configuring you call
[code]ccmake .[/code]
and press "t" for the advanced mode. Then you should find the entries
[ul]
  [li]BLAS_blas_LIBRARY[/li]
  [li]LAPACK_lapack_LIBRARY[/li]
[/ul]
On my VM with Ubuntu 16.04 they are set to "/usr/lib/libblas.so" and "/usr/lib/liblapack.so". All the other BLAS/LAPACK entries are set to not found, but that should be fine.

Regards,
Christoph

Hi Tim,

Netgen and NGSolve built from source correctly for me on a fresh Ubuntu 17.04 VM using the default instructions on the “install from sources” page. The only change I made was to substitute the github repository in the git clone command (git clone git://git.code.sf.net/p/ngsolve/git ngsolve-src changed to git clone GitHub - NGSolve/ngsolve: Netgen/NGSolve is a high performance multiphysics finite element software. It is widely used to analyze models from solid mechanics, fluid dynamics and electromagnetics. Due to its flexible Python interface new physical equations and solution algorithms can be implemented easily.). I didn’t do anything with cmake or ccmake.

I think the problem you were having building from source was an out of memory error. This causes the compiler to error out and, as I recall, the cmake script continues on and generates some spurious error messages about LAPACK and BLAS so the memory error may go unnoticed. The memory usage hits a peak of about 9GB about 45% into the ngsolve install.

I think Christoph’s post explains the issue with the nightly build and several other things.

Best,
Dow