Re: [Gmsh] Questions on 4.1 format

2020-03-30 Thread paul francedixhuit
Thanks Max and Christophe for the answers;
"Don't hesitate to contribute your feedback on
https://gitlab.onelab.info/gmsh/gmsh/-/issues/795 : we will use it to track
suggestions or corrections." -> I'll do





Le lun. 30 mars 2020 Γ  16:51, paul francedixhuit  a
Γ©crit :

> Hi All
> I'm currently having a look to the new 4.1 gmsh format.
>
> Compared to the previous 2.2 legacy one:
>
>- I guess *$Nodes* and *$Elements* for example use now blocs (or it
>has been splitted in blocs) in order to take advantages of parallelization,
>hasn't it?
>- *$Entities* and *$PhysicalNames* are used to define specific groups
>of elements to apply on specific features (typically sub-parts)
>
> Nonetheless concerning *$NodeData* (and *$ElementNodeData*), I've not
> tested it so far but I feel the structure remains identical to the 2.2 one:
> am I right? if so I can imagine improvements will be provided in a next
> future, won't be?
>
> The next steps will be to use it through the Python API 😊
>
> Bye
>
> Paul
>
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh


[Gmsh] Extrusion of one element that is split into multiple regions

2020-03-30 Thread Bucksot, Jesse Edward
Hi all,

I'm pretty new here. I've had good success with gmsh so far, but I just ran 
into an issue when extruding surfaces that have been split into multiple 
separate regions due to boolean operations. When I just do one extrude, it 
seems to come out right, but then if I try to label the extrusion (e.g. 
"Physical Volume("part") = {ex1[]};") or try to extrude again by extruding 
ex1[0], it only does one single part of the surface.
Basically, if I take a rectangle and cut it into two smaller rectangles using 
BooleanDifference and then extrude it, the created extrusion (ex1[0],ex1[1]) 
only contains one of the smaller rectangles and not both of them.

Does anyone have any solutions or workarounds to this?
Also, my real geometry is pretty complicated, so I'm not sure how feasible it 
is for me to manually check for any instances of surfaces being split apart 
before extruding.


Thanks in advance!
Jesse


mesh.geo
Description: mesh.geo
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh


Re: [Gmsh] Questions on 4.1 format

2020-03-30 Thread Max Orok
Hi Paul,

There's a discussion on the new format here that might be helpful:
https://gitlab.onelab.info/gmsh/gmsh/-/issues/444


On Mon, Mar 30, 2020 at 11:02 AM paul francedixhuit 
wrote:

> Hi All
> I'm currently having a look to the new 4.1 gmsh format.
>
> Compared to the previous 2.2 legacy one:
>
>- I guess *$Nodes* and *$Elements* for example use now blocs (or it
>has been splitted in blocs) in order to take advantages of parallelization,
>hasn't it?
>- *$Entities* and *$PhysicalNames* are used to define specific groups
>of elements to apply on specific features (typically sub-parts)
>
> Nonetheless concerning *$NodeData* (and *$ElementNodeData*), I've not
> tested it so far but I feel the structure remains identical to the 2.2 one:
> am I right? if so I can imagine improvements will be provided in a next
> future, won't be?
>
> The next steps will be to use it through the Python API 😊
>
> Bye
>
> Paul
> ___
> gmsh mailing list
> gmsh@onelab.info
> http://onelab.info/mailman/listinfo/gmsh
>


-- 
Max Orok
Contractor
www.mevex.com
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh


Re: [Gmsh] Questions on 4.1 format

2020-03-30 Thread Christophe Geuzaine

> On 30 Mar 2020, at 16:51, paul francedixhuit  wrote:
> 
> Hi All
> I'm currently having a look to the new 4.1 gmsh format.
> 
> Compared to the previous 2.2 legacy one:
>   β€’ I guess $Nodes and $Elements for example use now blocs (or it has 
> been splitted in blocs) in order to take advantages of parallelization, 
> hasn't it?

It allows that, yes. It also allows for much more efficient reading 
from/writing to disk.

But more fundamentally, the new format reflects the underlying Gmsh data model 
(http://gmsh.info/doc/texinfo/gmsh.html#Gmsh-API), and it contains all the 
information needed by Gmsh to save/reload a model without information loss.

>   β€’ $Entities and $PhysicalNames are used to define specific groups of 
> elements to apply on specific features (typically sub-parts)

Entities contain the underlying (topological) boundary representation of the 
Gmsh model. Physical groups are just groups of entities. They are defined even 
without a mesh. Mesh nodes/elements are stored in the model entities.

Note that the only two fields that are necessary in a simple MSH file are 
$Nodes and $Elements. All the rest is useful for Gmsh - but can be omitted by 
other codes if they don't need the additional topological model information.

> Nonetheless concerning $NodeData (and $ElementNodeData), I've not tested it 
> so far but I feel the structure remains identical to the 2.2 one: am I right? 
> if so I can imagine improvements will be provided in a next future, won't be?
> 

Yes indeed. See the end of the 
http://gmsh.info/doc/texinfo/gmsh.html#MSH-file-format section.

> The next steps will be to use it through the Python API 😊

The Python tutorial is now on par with the GEO and C++ ones: 
https://gitlab.onelab.info/gmsh/gmsh/-/tree/master/tutorial

New extended ("x") tutorials will be added in the near future to help new users 
with features that are only available through the API (and not in GEO files).

Don't hesitate to contribute your feedback on 
https://gitlab.onelab.info/gmsh/gmsh/-/issues/795 : we will use it to track 
suggestions or corrections.

Cheers,

Christophe

> 
> Bye
> 
> Paul
> ___
> gmsh mailing list
> gmsh@onelab.info
> http://onelab.info/mailman/listinfo/gmsh

β€” 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science 
http://www.montefiore.ulg.ac.be/~geuzaine




___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh


[Gmsh] Questions on 4.1 format

2020-03-30 Thread paul francedixhuit
Hi All
I'm currently having a look to the new 4.1 gmsh format.

Compared to the previous 2.2 legacy one:

   - I guess *$Nodes* and *$Elements* for example use now blocs (or it has
   been splitted in blocs) in order to take advantages of parallelization,
   hasn't it?
   - *$Entities* and *$PhysicalNames* are used to define specific groups of
   elements to apply on specific features (typically sub-parts)

Nonetheless concerning *$NodeData* (and *$ElementNodeData*), I've not
tested it so far but I feel the structure remains identical to the 2.2 one:
am I right? if so I can imagine improvements will be provided in a next
future, won't be?

The next steps will be to use it through the Python API 😊

Bye

Paul
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh


[Gmsh] Variable thickness surface

2020-03-30 Thread Julian
Hello,

I am using gmsh for modelling 2D components and I am trying to find out how
I can set a thickness to the plate/shell elements. First I was thinking
about assigning regions of different thicknesses to different physical
groups but by this approach I can specify only a constant value which is
not what I need.

According to this conversation from the mailing list it should be possible.

>
> Hi Mathieu,
> Have a look at the Gmsh Tutorial 7:
> http://geuz.org/gmsh/doc/texinfo/gmsh.html#t7_002egeo
> HTH
> Ruth
> Dr. Ir. Ruth V. Sabariego
> University of Liege, Electrical Engineering & Computer Science,
> Applied & Computational Electromagnetics (ACE),
> phone: +32-4-3663737 - fax: +32-4-3662910 -
> http://ace.montefiore.ulg.ac.be/


On 13 Oct 2011, at 12:27, Mathieu ARQUIER wrote:
>
> Hello,
>
> First of all, thank you very much for developing GMSH !!! I used it for
> several years now as pre-processor to create meshes for my structural
> calculation software and it works very well :).
> Now, I want to go further and would like to create variable thickness
> shell elements. So, I was wondering if there is a way to interpolate a
> scalar field inside a 2D meshed surfaced (i.e. the thickness) ? Basically,
> I want to define a surface with a variable thickness (let's say I know the
> value at some nodes of its border), and, once the meshing has been done, I
> want to retrieve the value of the interpolated thickness at each new
> created nodes inside the surface in order to define variable thickness
> shell elements.
> Do you see any way to do so ?
> Thank you in advance !
>
> Best regards,
>
> Mathieu ARQUIER
> Structural Engineer
> mathieu.arquier at gmail.com
>

I checked the tutorial 7 he referred to. In my opionion this examples
controls the size of the elements by using a *.pos file and not controlling
the thickness. So my question is how I can assign a thickness for example
to a rectangle area as a linear function from 1 to 10 in x-direction and
constant in y-direction?

Best regards
Julian
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh