#1264 Coordinates not computed correctly when downsampling stretched grids
See email below. Test data are in /glade/p/DASG/VAPOR/Bugs/<bugid>
On Jun 29, 2016, at 3:22 AM, Klaus Galsgaard kg@nbi.ku.dk wrote:
Hi vapor developer,
I have been using vapor for quit some time now, and has found a problem that is
a little annoying. When you are using data on a stretched grid then only the highest
refinement level uses the correct positions. Lower refinements seems to be using
a uniform grid. This prevents one from using the lower refinements to make
data investigations and makes it impossible to combine different refinements for
different variables. I have attached two images that shows the problem. They show
the same simple variable with variations along the direction with stretched coordinates.
In this case the grid has the highest space density low down, which is seen in the refinement 1
image. The refinement 0 image clearly show a different spatial distribution of the physics
variable.....
This is a problem in version 2.4.2 and also in 2.5.
The data has been converted using your raw2vdf routines, while the *.vdf file was created using
vdfcreate ... gridtype stretched -xcoords xcoords.dat ....
where the xcoords.dat contains the grid positions on the heights resolution.
Hope you can fix the problem.
All the best,
Klaus Galsgaard
--
Klaus Galsgaard
Niels Bohr Institute
Geological Museum
5-7 Østervoldgade
Dk-1350 Copenhagen K
Denmark
On Jun 30, 2016, at 6:17 AM, Klaus Galsgaard kg@nbi.ku.dk wrote:
Hi John,
This was a little challenge to make a data set you can use to test the problem. When I tried to make a teset setup I noticed that the stretching worked as it should, until I started play with the number of datapoints in the stretched direction. I am using the latest version 2.5.0 for this and are using the linux distribution.
I have included a tar file that contains a number of files.
tar -ztvf vapor_stretch_test.tgz there are a few more files than needed, these are the important ones:
a simple session showing a 2D probe along the stretch direction
-rw-r--r-- kg/astro 18911 2016-06-30 11:08 VaporSaved.vss
idl script that generates the vdf data Notice the stretching is in the x direction and follows an exp function.
-rw-r--r-- kg/astro 473 2016-06-30 11:06 init.jou
Data with 100x10x10 gridpoints where the stretching is working for level 0 and 1
-rw-r--r-- kg/astro 2221 2016-06-30 11:06 test_100.vdf
drwxr-xr-x kg/astro 0 2016-06-30 11:06 test_100_data/
drwxr-xr-x kg/astro 0 2016-06-30 11:06 test_100_data/rho/
-rw-r--r-- kg/astro 262952 2016-06-30 11:06 test_100_data/rho/rho.0000.nc0
-rw-r--r-- kg/astro 1835832 2016-06-30 11:06 test_100_data/rho/rho.0000.nc1
Data with 101x10x10 gridpoints where the stretching is not forking to level 0
-rw-r--r-- kg/astro 2234 2016-06-30 11:06 test_101.vdf
drwxr-xr-x kg/astro 0 2016-06-30 11:06 test_101_data/
drwxr-xr-x kg/astro 0 2016-06-30 11:06 test_101_data/rho/
-rw-r--r-- kg/astro 262952 2016-06-30 11:06 test_101_data/rho/rho.0000.nc0
-rw-r--r-- kg/astro 1835832 2016-06-30 11:06 test_101_data/rho/rho.0000.nc1
idl program used to write data defined in init.jou
-rw-r--r-- kg/astro 3602 2016-06-30 11:09 vdf.pro
Also attahced are two images showing the level 0 and 1 for the 101x10x10 data set.
where the level 1 is the one that correctly represents the data.
Hope this can help you solving the problem.
All the best,
klaus