Great, thank you. Could you clarify what are the 9 values that you associate
with the element and with each node?
A.
-Messaggio originale-
Da: Christophe Geuzaine [mailto:cgeuza...@uliege.be]
Inviato: giovedì 31 gennaio 2019 09:46
A: Alessandro Vicini
Cc: gmsh@onelab.info
Oggetto:
Ok, got it, in this case you are associating one tensor to the cell and to the
nodes.
My question is: I have a number of scalar fields, some defined on the nodes,
other defined on cell centers. Can I associate all the scalar fields in the
same view (one for elements and one for nodes), or do I
> On 31 Jan 2019, at 10:26, Alessandro Vicini
> wrote:
>
>
> Great, thank you. Could you clarify what are the 9 values that you associate
> with the element and with each node?
the 9 tensor components, per row
>
> A.
>
>
> -Messaggio originale-
> Da: Christophe Geuzaine
> On 30 Jan 2019, at 23:58, Max Orok wrote:
>
> Yes, the stresses belong in the $ElementData section for sure.
> I think to correctly display it, you'll need to create rows of element data
> with 10 entries - 1 for the element number and 9 for the stress tensor values:
>
> 1 sigx sigxy
I would be grateful if you could post a similar MSH2 example for a tetrahedron
grid, with 1 data field assigned on nodes and another one assigned on cell
centers...
A.
-Messaggio originale-
Da: gmsh [mailto:gmsh-boun...@ace20.montefiore.ulg.ac.be] Per conto di
Christophe Geuzaine
> On 31 Jan 2019, at 09:40, Alessandro Vicini
> wrote:
>
>
> I would be grateful if you could post a similar MSH2 example for a
> tetrahedron grid, with 1 data field assigned on nodes and another one
> assigned on cell centers...
>
Here we go:
$MeshFormat
2.0 0 8
$EndMeshFormat
$Nodes
4
Your 2 volumes overlap. Either explicitly construct the 2 volumes so that they
don't overlap, i.e. one on top of the other. Or use the OpenCASCADE factory and
fragment the volumes at the end (e.g. using "Coherence" - see attached example)
- although this is really overkill in this case.
Can you send a test file?
I tried this, i.e. adding 1000 embedded points in a volume, and it is quite
fast (< 2 seconds):
SetFactory("OpenCASCADE");
Box(1) = {0,0,0, 1,1,1};
For i In {1:1000}
Point(100+i) = {0.25 + 5e-4*i, 0.1,0.1};
Point{100+i} In Volume{1};
EndFor
Maybe you modify the
Dear Sir or Madam,
some more details on the previously-reported case of extremely slow parsing
of a gmsh file:
The file contains 34795 points -- of which 23041 points are "Point In
Volume" (e.g. embedded_vertices of a GRegion?). Moreover, it contains 4998
"Plane Surface"s and one single "Volume".
Dear Sir or Madam,
some gmsh-file of mine (roughly 10 lines) takes extremely much time to
load: Just the parsing of gmsh (in both version 3.x.x and 4.x.x) takes
about 45 minutes to 1 hour.
However, in contrast, the parsing of the resulting mesh, which is of
similar complexity, takes only some
This was precisely the point of my example: if you embed the point after each
point is created, you force a rebuild of the topology of the model. So the
efficient script would be
SetFactory("OpenCASCADE");
Box(1) = {0,0,0, 1,1,1};
N=1;
For i In {1:N}
Point(100+i) = {0.25 + 5e-5*i,
Dear Christophe,
my example files are scientific data, however originate from processing
certain proprietary 3D models that were shared with me under certain
restrictions. Therefore, it's difficult to share my original file with you.
However, I was indeed able to reproduce the issue using only a
Dear Christophe,
I tried out your gmsh-file with "Point{100+1:100+N} In Volume{1};" and it's
indeed much faster!
That indeed seems to be the solution I needed -- thanks a lot!
As I don't really know much about the internal functionality of gmsh, it
would have been almost impossible for me to
> On 31 Jan 2019, at 15:19, Al Sc wrote:
>
> Dear Christophe,
>
> I tried out your gmsh-file with "Point{100+1:100+N} In Volume{1};" and it's
> indeed much faster!
> That indeed seems to be the solution I needed -- thanks a lot!
>
> As I don't really know much about the internal
Hello,
Are you referring to an input geo file which is taking so long?
What sort of operations are you doing in the file?
Sincerely,
Max
On Thu, Jan 31, 2019 at 8:21 AM Al Sc wrote:
> Dear Sir or Madam,
>
> some gmsh-file of mine (roughly 10 lines) takes extremely much time to
> load:
Dear Christoph,
to be honest, a remark deeply hidden somewhere in the documentation
wouldn't have helped me.
That's because my approach typically is not to read the documentation like
a book (i.e. from front to back) but rather to skip forwards to the
paragraphs I currently need for the
Dear Max,
thanks for your support! However, Christophe Geuzaine already solved this
issue for me -- see other thread << [Gmsh] "Re: GMSH parsing is very slow"
>>.
Sorry for the confusion.
Best regards,
A. S.
Am Do., 31. Jan. 2019 um 15:16 Uhr schrieb Max Orok :
> Hello,
>
> Are you referring
> On 31 Jan 2019, at 15:48, Al Sc wrote:
>
> Dear Christoph,
>
> to be honest, a remark deeply hidden somewhere in the documentation wouldn't
> have helped me.
> That's because my approach typically is not to read the documentation like a
> book (i.e. from front to back) but rather to skip
18 matches
Mail list logo
