[rcastilla]

I have realized a weird behavior of sample utility with uniform output in a line. The sampleDict is this:

sets
(
lineX1

{
type uniform;
axis distance; //- cavity. Slightly perturbed so not to align with face or edge.
start (0.001 1.03378237608 1.05133165821);
end (-0.001 1.92579242682 1.85402591468);
nPoints 121;

}

The x-coordinates are missaligned with faces (I though first that it was the problem...). The result seems to be ok, but the distances to the first point are unsorted. It is like that:

0 1.90715e-06
0.01 1.70956e-06
0.02 1.51302e-06
0.03 1.31648e-06
0.0400001 1.11995e-06
0.0500001 9.2341e-07
0.0600001 7.98367e-07
0.0700001 7.32603e-07
0.0800001 6.66839e-07
0.0900001 6.01075e-07
0.1 5.3531e-07
0.11 4.70314e-07
0.12 3.9017e-07
0.13 3.17752e-07
0.14 2.45334e-07
0.15 1.72916e-07
0.16 1.28532e-07
0.17 1.13823e-07
0.18 9.91135e-08
0.19 8.44043e-08
0.2 6.96952e-08
0.21 5.4986e-08
0.22 4.02769e-08
0.23 3.05289e-08
0.24 2.26816e-08
0.25 1.48344e-08
0.450001 3.583e-08
0.460001 1.60833e-07
0.470001 2.85836e-07
...
...
1.18 1.56143e-06
1.19 1.63099e-06
1.2 1.69496e-06
0.26 1.68889e-06
0.27 1.68282e-06
0.28 1.67676e-06
0.29 1.67069e-06
0.3 1.66462e-06
0.31 1.58344e-06
...
...
0.420001 6.53034e-07
0.430001 5.84224e-07
0.440001 5.15415e-07

It seems that if the distances are sorted (but NOT the second column), the output is ok. I mean, I obtain the same result as in "Plot over line" in paraview. I can write a code in python as a workaround, but it is quite annoying.

I have checked the sample utility code in order to find the writing function, but I have to admit that I get lost in the first includes...

Has somebody faced this problem before? Is it a bug of sample? Is there a solution for that?

With best regards

Robert

[rcastilla]

I have forgotten to say that the sample utility was ran in a descomposed case, that is, in parallel, with 16 processors. I have been making new tests and, if the data is reconstructed it works as expected!. So, this seems to be a problem with reconstruction of data inside the sample utility.

Best regards

Robert

[Phil_]

Hey,

I have a similar problem with unsorted values when sampling a patch in a 2D geometry (front and back faces of type empty).

surfaces
(
    lowerWall
    {
    type        patch;
    patches        (lowerWall);
    interpolate    false; //true
    triangulate    false; //true
    }
)

The first values are perfectly sorted, but then they somehow get mixed up...

0.37 0 0
0.37 0 0.001
0.368 -1.0842e-21 0.001
0.368 -1.0842e-21 0
0.366 -2.1684e-21 0
0.366 -2.1684e-21 0.001
0.364 -3.25261e-21 0
0.364 -3.25261e-21 0.001
0.362 -4.33681e-21 0
0.362 -4.33681e-21 0.001
...
...
0.32 -2.71051e-20 0.001
0.25 -0.0254 0
0.251979 -0.0253388 0
0.251979 -0.0253388 0.001
0.25 -0.0254 0.001
0.253951 -0.0251651 0
0.255912 -0.0248867 0
0.255912 -0.0248867 0.001
0.253951 -0.0251651 0.001
0.257856 -0.0245122 0
0.259782 -0.0240509 0
0.259782 -0.0240509 0.001
0.257856 -0.0245122 0.001
0.261687 -0.0235124 0
0.263572 -0.0229056 0
...
...

Is this an user error or an issue of the sample tool?

Best regards

Philip

[rcastilla]

Hi, Phil,

is your case decompesed? If so, try with the reconstructed case.

Regards

Robert

[Phil_]

Hey Robert,

no it's not decomposed.

Maybe it has something to do with the fact, that the mesh is imported from SALOME.

Best regards

Philip

[kingjewel1]

Originally Posted by rcastilla

I have realized a weird behavior of sample utility with uniform output in a line. The sampleDict is this:

sets
(
lineX1

{
type uniform;
axis distance; //- cavity. Slightly perturbed so not to align with face or edge.
start (0.001 1.03378237608 1.05133165821);
end (-0.001 1.92579242682 1.85402591468);
nPoints 121;

}

The x-coordinates are missaligned with faces (I though first that it was the problem...). The result seems to be ok, but the distances to the first point are unsorted. It is like that:

0 1.90715e-06
0.01 1.70956e-06
0.02 1.51302e-06
0.03 1.31648e-06
0.0400001 1.11995e-06
0.0500001 9.2341e-07
0.0600001 7.98367e-07
0.0700001 7.32603e-07
0.0800001 6.66839e-07
0.0900001 6.01075e-07
0.1 5.3531e-07
0.11 4.70314e-07
0.12 3.9017e-07
0.13 3.17752e-07
0.14 2.45334e-07
0.15 1.72916e-07
0.16 1.28532e-07
0.17 1.13823e-07
0.18 9.91135e-08
0.19 8.44043e-08
0.2 6.96952e-08
0.21 5.4986e-08
0.22 4.02769e-08
0.23 3.05289e-08
0.24 2.26816e-08
0.25 1.48344e-08
0.450001 3.583e-08
0.460001 1.60833e-07
0.470001 2.85836e-07
...
...
1.18 1.56143e-06
1.19 1.63099e-06
1.2 1.69496e-06
0.26 1.68889e-06
0.27 1.68282e-06
0.28 1.67676e-06
0.29 1.67069e-06
0.3 1.66462e-06
0.31 1.58344e-06
...
...
0.420001 6.53034e-07
0.430001 5.84224e-07
0.440001 5.15415e-07

It seems that if the distances are sorted (but NOT the second column), the output is ok. I mean, I obtain the same result as in "Plot over line" in paraview. I can write a code in python as a workaround, but it is quite annoying.

I have checked the sample utility code in order to find the writing function, but I have to admit that I get lost in the first includes...

Has somebody faced this problem before? Is it a bug of sample? Is there a solution for that?

With best regards

Robert

Hi Robert,

Did you ever sort this problem? I have the same thing in OF2.3.1. But not only are the values unsorted, the sample lines aren't as long as I request. Sometimes only 5 or 6 points out of 100... What do you think?