gridgen-c warning: F(): NaN detected or Segmentation fault

[sdsjkj]

Dear, all;

The following python code perfectly worked in a company where I worked internship.

import numpy as np
import octant
x=np.array([0, 0, -3, -3, 0, 0, 5, 5])
y=np.array([5, 3, 4, 3, 2, 0, 0, 5])
grd=octant.grid.Gridgen(x,y,beta,(32,32))

The company used GNU compilers for C and C++, PGI fortran compiler.
To use octant in my 64bit laptop(Intel core i5 m460), I installed Ubuntu 10.10 and all libraries with GNU compilers(gcc-4.4).
Then I ran the above same codes and The error, Segmentation fault, came up.
With another code(That also worked perfectly in the company), the error "F(): NaN detected" in Function F of gridgen.c came up although I changed newton value and slightly moved the boundary polygon vertices. I know the error is from NaN detected in f() array but could not figure it out. In case, it only worked properly when I made the polygon boundary like a rectangular.
Plase let me know any clue about thses problems.

Thank you in advance!
Don

PS: I found building errors and warnings when I configure ATLAS-3.9.32 with the instruction from http://www.scipy.org/Installing_SciPy/Linux. The errors are as following.

gcc -I/home/sdsjkj/local/ATLAS/BUILD/..//CONFIG/include -g -w -o xconfig /home/sdsjkj/local/ATLAS/BUILD/..//CONFIG/src/config.c atlconf_misc.o
atlconf_misc.o: In function `CmndResults':
/home/sdsjkj/local/ATLAS/BUILD/..//CONFIG/src/atlconf_misc.c:306: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
./xconfig -d s /home/sdsjkj/local/ATLAS/BUILD/../ -d b /home/sdsjkj/local/ATLAS/BUILD -A 18 -Si nof77 0 -Si cputhrchk 0 -D c -DPentiumCPS=2534 -b 64 -Fa alg -fPIC -Si lapackref 1
atlconf_misc.o: In function `CmndResults':
/home/sdsjkj/local/ATLAS/BUILD/..//CONFIG/src/atlconf_misc.c:306: warning: the use of `tmpnam' is dangerous, better use `mkstemp'

OS configured as Linux (1)
atlconf_misc.o: In function `CmndResults':
/home/sdsjkj/local/ATLAS/BUILD/..//CONFIG/src/atlconf_misc.c:306: warning: the use of `tmpnam' is dangerous, better use `mkstemp'

Assembly configured as GAS_x8664 (2)
atlconf_misc.o: In function `CmndResults':
/home/sdsjkj/local/ATLAS/BUILD/..//CONFIG/src/atlconf_misc.c:306: warning: the use of `tmpnam' is dangerous, better use `mkstemp'

Vector ISA Extension configured as SSE3 (3,56)
atlconf_misc.o: In function `CmndResults':
/home/sdsjkj/local/ATLAS/BUILD/..//CONFIG/src/atlconf_misc.c:306: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
ERROR: enum fam=3, chip=2, mach=0
make[3]: *** [atlas_run] Error 44
make[2]: *** [IRunArchInfo_x86] Error 2
atlconf_misc_BE.o: In function `CmndResults':
/home/sdsjkj/local/ATLAS/BUILD/..//CONFIG/src/atlconf_misc.c:306: warning: the use of `tmpnam' is dangerous, better use `mkstemp'

Clock rate configured as 2534Mhz
ERROR: enum fam=3, chip=2, mach=0
make[3]: *** [atlas_run] Error 44
make[2]: *** [IRunArchInfo_x86] Error 2

Maximum number of threads configured as 4
atlconf_misc.o: In function `CmndResults':
/home/sdsjkj/local/ATLAS/BUILD/..//CONFIG/src/atlconf_misc.c:306: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
Parallel make command configured as '$(MAKE) -j 4'
ERROR: enum fam=3, chip=2, mach=0
make[3]: *** [atlas_run] Error 44
make[2]: *** [IRunArchInfo_x86] Error 2
Cannot detect CPU throttling.

I googled for long time but couldn't figure them out yet.
Does anyone have an idea about this issue?
I will really appreciate with any comment.

[kate]

Can you check to see if the Gridgen routine has some optional arguments? I know you need to tell gridgen which corners are concave and which are convex when you have more than the default four corners. Or is that beta?

[hetland]

Can you see if your code works with a square, that is

Code: Select all

x = [1, 0, 0, 1]
y = [1.1, 1.0, 0., 0.]
beta = [1, 1, 1, 1]

That way you can isolate the problem to the gridgen library.

Also, I seem to remember some issues with compiling the gridgen library with 64 bit. I have found that 32 bit python, numpy, etc is just as fast -- do you have a particular need for 64 bit?

Finally, how did you install the gridgen libraries? I know that I have gone back and fourth between having python setup compile the libraries, and installing them by hand. I'm not sure which version you are using.

-Rob

p.s. I would be curious to know which company you worked for? I'm always amazed when people find octant useful. Also, be sure to send along any bug fixes.

[sdsjkj]

Thank you so much for your prompt answers.

Dear, Kate;
I am sorry for missing beta values in the question. Actually, "beta=np.array([1,-1,1,1,-1,1,1,1])" has been included in my code script.
Thank you so much anyway!

Dear, Robert Hetland;
Segmentation fault occured with the square coordinate but I moved y coordinates onto y=[2, 1, 0, 0], then no error came up.
I checked out the latest gridgen-c 1.47 and the other latest dependents with subversion and saved them in my external directory of octant-read-only.
Although I knew the sources(csa, gridgen,gridutils,nn) are already in your external directory, I downloaded the latest versions in the external directory because I experienced that octant doesn't work properly with the existing gridgen and the others in your external directory(Issue 2 in your octant google website).
So I installed the latest nn, csa, gridutils and gridgen by hand and run python build and install with prefix.
Finally, I moved the libgridgen.so into octant directory of site-packages.

I don't have the particular need for 64 bit yet but I thought 64bit python and numpy were installed in the company cluster. I will make sure that.
Also, python-2.6.6 is installed by default with Ubuntu10.10(64bit).

Sincerely yours,
Don

P.S. I worked for St. Johns River Water Management District for a while. My supervisor in the company was interested in ROMS but I don't think he is using it now. By the way, I am back to school for doctoral degree and trying to learn ROMS model and Octant. I have been familiar with Matlab but now trying to use python and octant because octant is quite useful .

[hetland]

Well, since you can get octant.gridgen to work (I assume the output of the square looked sensible?), then it must be the gridgen library.

I still suspect this might be a 32/64 bit issue.

There are many options to put into griggen to tell how many times to itterate, for example. You can try to modify these. Otherwise, you might want to see if gridgen (the command line call) works for the examples that it comes with when you compile 32 or 64 bit.

Good luck,

-Rob

[sdsjkj]

I will try it.

Thank you!
Don

[sak007]

Then I ran the above same codes and The error, Segmentation fault, came up.
With another code(That also worked perfectly in the company), the error "F(): NaN detected" in Function F of gridgen.c came up although I changed newton value and slightly moved the boundary polygon vertices.

Try to remove the file with sigmas, for two reasons.

Firstly, the solution is saved to this file in binary format. There is a good chance that things could go wrong with it on a different system.

Secondly, when this file is present, gridgen starts from the saved solution. This is supposed to skip the iterative process in the case if only the angles have changed but not the vertices (when say one has a fixed boundary polygon and tries different corner positions). Deleting it forces gridgen to start the iterative process from scratch.

Good luck
Pavel

[sdsjkj]

Dear, Pavel Sakov;

I am sorry I couldn't understand which file I can remove with sigmas.
Thank you so much for your comment.

Sincerely yours,
Don

[sak007]

I am sorry I couldn't understand which file I can remove with sigmas.
Thank you so much for your comment.

Dear Don,

Right... After looking at the octave code - it seems that it does not save sigmas to disk (Rob?). Then my comment has no relevance to your situation.

I have no other ideas. The problem seems to be system related. I can only second Rob's suggestion - to test whether you can build examples from the gridgen package. This would allow to pin the problem to octave or gridgen.

Cheers
Pavel

[hetland]

Right... After looking at the octant code - it seems that it does not save sigmas to disk (Rob?).

If you are using a later version of octant that calls the gridgen libraries directly (instead of a straight command line call to gridgen), no files are saved. I think this is what you are using, so you won't find any files.

[sdsjkj]

Dear, all;

Finally, I figured it out.
It wasn't trouble with Octant and gridgen-c but my stupid fault.
I am so sorry for that.

I linked self.libgridgen to the newest libgridgen.so I installed.
Then it works now in 64bit Ubuntu although warning(invalid value encountered in sqrt) occured.
Thank you so much for all.

Sincerely yours,
Sangdon

[asujrpv]

Sangdon, could you please tell me how you did you link self.libgridgen to the newest libgridgen.so? I do not have self.libgridgen.

I am having exactly the same problem you have described.
The code I used is:

import numpy as np
import octant
x=np.array([0, 0, -3, -3, 0, 0, 5, 5])
y=np.array([5, 3, 4, 3, 2, 0, 0, 5])
beta=np.array([1,-1,1,1,-1,1,1,1])
grd=octant.grid.Gridgen(x,y,beta,(32,32))


and the errors are >>> import numpy as np
>>> import octant
/usr/local/lib/python2.6/dist-packages/matplotlib/numerix/__init__.py:18: DeprecationWarning:
**********************************************************
matplotlib.numerix and all its subpackages are deprecated.
They will be removed soon. Please use numpy instead.
**********************************************************

warnings.warn(msg, DeprecationWarning)
/usr/local/lib/python2.6/dist-packages/mpl_toolkits/__init__.py:2: UserWarning: Module dateutil was already imported from /usr/local/lib/python2.6/dist-packages/dateutil/__init__.pyc, but /usr/lib/pymodules/python2.6 is being added to sys.path
__import__('pkg_resources').declare_namespace(__name__)
>>> x=np.array([0, 0, -3, -3, 0, 0, 5, 5])
>>> y=np.array([5, 3, 4, 3, 2, 0, 0, 5])
>>> beta=np.array([1,-1,1,1,-1,1,1,1])
>>> grd=octant.grid.Gridgen(x,y,beta,(32,32))
/usr/local/lib/python2.6/dist-packages/octant
error: F(): NaN detected




Thanks!
Rafael