Equilibirum runs only work on curvilinear grids if you do gridflag=0 (close dipole), even if the grid is set up as an open dipole

[jdiazpena]

When running an eq simulation, if gridflag is set up to anything but 0 (close dipole), it breaks after a free in model hours (timestep reaches 0). The best example is the saidcurv_eq in gemini-examples, which has a gridflag=0 but grid conditions that make it open dipole.

Matlab and Python wrappers end with the same error (timestep reaches 0). If run with gridflag=0, there are no issues and Gemini3D itself then calculates the type of grid

[paulinchin]

I have open grids that ran for EQ properly (e.g., figure 1 below). But I admit it can be tricky, depending on how grid looks like. In some cases errors accumulate at top boundary if top corners have very different altitudes (figure 2 below).

[mattzett]

Joaquin - are you still having this problem? If so can you post and image similar to what Paul gives above to see if it is a boundary thing.

[jdiazpena]

I still have this issue. I can only run eq with a gridflag of 0. If I choose any other number, the simulation fails. If I try to run a non-eq simulation with gridflag different than 0, pygemini catches it and stops the simulation saying that there is a negative density.

What I found is that inside gemini3d it checks the grid and makes decisions on what type it is, so even with a 0 it works as an inverted grid on my case.

[mattzett]

It sounds to me like the problem is related to the generation of the initial conditions for the eq run; i.e. if you end up with a worker than has all cells below the ionosphere it will think there is a problem with the initial density, when there really isn't -- though probably your grid is not the most efficient choice.

[mattzett]

arguably the error checking is too aggressive here, since I'm guessing the simulation would run fine and produce acceptable output if this were ignored. On the other hand this is a sign that the grid you've made has too many cells in places that aren't useful.