Hi Markus, lglel reads "local to global element number" so input is local element number and output is global element number. I'll be seeing Stefan this week so I'm sure we can straighten out the interpolation routines. You're right about the other points - the ntotv wasn't flagged by my compiler and the .his file was taken care of by my own scripts, so I didn't catch either of them. Sorry about that. I've updated the source so that those issues should be resolved. Paul On Mon, 12 Jul 2010, [email protected] wrote:
Hi,
that was not it, I'm afraid (though I thought gllel transforms from local to global).
But I also realized that the hpts routine does not deliver the correct values for me. To test this, I set up a simple 3d box with inflow, outflow and symmetry all around, Re very low, initial condition=boundary condition and 4 points. Please find all files attached, the output for the first point is OK, but then the values seem to shift positions and don't make sense.
Also, when running it for 1 step or more, I get the error message: " dump history points done :: dump history points hisfile: /Users/m0s1978/nektonruns/rectest/rectest.his
ERROR: .sch file already exists. ierr= 1 "
And lastly, the newest repo won't compile, here is the error message: " Error: /Users/m0s1978/nek5trial/trunk/nek/drive2.f, line 1551: This name has already been assigned a data type. [NVTOT] integer*8 ntot,nvtot,nptot ---------------------^ "
Thanks for any help, Markus
[email protected] wrote:
Hi Markus,
It's possible that it's returning the local (to the processor) element number. You would get the global (to the computational domain, defined by the .rea file) element number via:
integer e,eg
eg = lglel(e)
Paul
On Sun, 11 Jul 2010, [email protected] wrote:
Hi again,
Regarding finding element numbers (such as what gllel would return) for arbitrary history points, I was experimenting with the history point routine hpts a little and it seems that this function call:
call findpts(inth_hpts,rcode,1, & proc,1, & elid,1, & rst,ndim, & dist,1, & pts(1,1),ndim, & pts(2,1),ndim, & pts(3,1),ndim,npoints)
does not return the same element number (elid) as it can be found in the .rea file, for instance. For a handful of manually set points, I checked that the returned element number does not provide the right coordinates to enclose the desired point.
Is there a way to transform the function return or am I missing something else?
Thanks, Markus
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users