sakov/gridgen-c

Orthogonal multi-corner grid generator

gridgen-c's Issues

metric elements

Hi,
is there a way to get the metric elements of the generated grid in order to transform equations to the new coordinates?
best
Matthias

Very nice tool: updates?

No problem to report, just an inquiry as to if you plan on enhancing or
updating this project in the future.  For larger grids, the algorithm is
quite slow as compared to other grid generation software.  However, beggars
cant be choosers and this is great work!  
Thank you.  

Original issue reported on code.google.com by britton.olson on 28 May 2010 at 4:10

grid dimensions not always specified in the output data file

If an input file with custom grid is provided, then output data file misses the 
first line with grid dimensions like "## 123 x 456". This "header" is very 
useful for further processing of the generated grid.

PS:
Thanks a LOT for very useful tool! What is the best way to reference it in own 
publications? I mean the dedicated item in a references list. Do you have any 
papers concerning the gridgen? Or the title and URL of this site will be enough?

Original issue reported on code.google.com by [email protected] on 13 Oct 2010 at 4:44

Issue a GitHub release

Dear @sakov,

I maintain a repository of various software used by oceanographer where nn, csa, gridgen, and gridutils are part of the software stack I package.

It would be nice if you could issue an official GitHub release of the latest version (v1.49). Also for nn, csa, and gridutils.

This would help us to sort out a "fork mess" we have right now. (See ioos/conda-recipes#307 (comment)).

I just checked gridgen and it seems that the forks had no active development except for this PR, since I am the author of that PR I can just redirect it here. I will take a closer look at the rest of the stack later today.

Thanks for the attention!

PS1: The packaging tool of choice is conda, but all packagers out there would take advantaged of a released version.

PS2: Ping @phobson who maintain the active forks and can say more about the differences and what should be pushed upstream.

"F(): NaN detected" or "Segmentation fault"

Dear,

I know this site is for gridgen-c.
Pardon me I am asking the issue here. It might be related with octant.
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 gridgen with octant GUI interface in my 64bit laptop, I installed Ubuntu 
10.10 and all libraries with GNU compilers.
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 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 but could not figure it out. When I made the polygon 
boundary like a rectangular, it only worked.
Plase let me know any clue about the problem.

Thank you in advance!
Don








They used GNU compiler and PGI fortran compiler. 

Original issue reported on code.google.com by [email protected] on 9 Dec 2010 at 12:33

grid dimensions not always specified in the output data file

If an input file with custom grid is provided, then output data file misses the 
first line with grid dimensions like "## 123 x 456". This "header" is very 
useful for further processing of the generated grid.

PS:
Thanks a LOT for very useful tool! What is the best way to reference it in own 
publications? I mean the dedicated item in a references list. Do you have any 
papers concerning the gridgen? Or the title and URL of this site will be enough?

Original issue reported on code.google.com by [email protected] on 13 Oct 2010 at 4:44

fatal error: gridnodes.h: No such file or directory

I am having trouble getting gridgen installed on OSX. I compiled nn, csa, and gridutils without any issues as far as I can see. I configured gridgen with the following:

CPPFLAGS="-I${DESTDIR}/include" LDFLAGS='-L/usr/local/lib -lgu' \
LD_LIBRARY_PATH='-L/usr/local/lib' LIBS='-L/usr/local/lib -lgu' \
LT_SYS_LIBRARY_PATH='/usr/bin' CFLAGS='-O2' \
./configure --prefix=${DESTDIR} --includedir=${DESTDIR}/include

The configuration runs fine, notably this section:

checking gridnodes.h usability... yes
checking gridnodes.h presence... yes
checking for gridnodes.h... yes
checking for gridnodes_readnextpoint in -lgu... yes
configure: creating ./config.status
config.status: creating makefile
config.status: creating config.h

However, when I execute sudo make I get the following output:

gcc -c -DTRILIBRARY -O2 -w -ffloat-store -I. triangle.c
gcc -o gridgen -DGRIDGEN_STANDALONE -O2 main.c broyden.c delaunay.c geom.c gridgen.c hash.c issimplepoly.c istack.c ode.c swcr.c vertlist.c zode.c triangle.o -L/usr/local/lib -lgu -lm
In file included from main.c:24:0:
gridgen.h:26:23: fatal error: gridnodes.h: No such file or directory
compilation terminated.
In file included from gridgen.c:37:0:
gridgen.h:26:23: fatal error: gridnodes.h: No such file or directory
compilation terminated.
make: *** [gridgen] Error 1

Does anyone have any idea what I'm doing wrong? Thanks.

grid dimensions not always specified in the output data file

If an input file with custom grid is provided, then output data file misses the 
first line with grid dimensions like "## 123 x 456". This "header" is very 
useful for further processing of the generated grid.

PS:
Thanks a LOT for very useful tool! What is the best way to reference it in own 
publications? I mean the dedicated item in a references list. Do you have any 
papers concerning the gridgen? Or the title and URL of this site will be enough?

Original issue reported on code.google.com by [email protected] on 13 Oct 2010 at 4:46

Parameter "nppe" don't work

The docs mention the following useful parameter
  nppe <number of points per internal edge>] (3)
But it do nothing when placed in parameters file.

It seems that it's just a misprint:

---
gridgen.c, line 699:
    if (prm_read(prmfname, prm, "ppe", buf))
        gg->nppe = atoi(buf);
    gg->nppq = gg->nppe * 4 + 5;

---

Original issue reported on code.google.com by [email protected] on 6 Nov 2009 at 10:54

broken google code links

Thanks for your work on this wonderful project! I was hoping to read more about the underlying algorithms, but the links to Google code are broken now that it's been shut down completely. Do you still have these documents? If you're concerned about keeping large files in version control, you could use git-lfs.

O-mesh capability

Thanks again for the great tool.  Use it nearly daily.  I've noticed that it is 
very difficult to make an O-mesh, like a grid around an airfoil, as doing so 
collocates corner points and creates a divide by zero scenario.  Any 
suggestions?

Thanks!

Original issue reported on code.google.com by britton.olson on 21 Jan 2011 at 12:25