Comments on AMELET-HDF doc v0.6

[Grégory Moura]

Dear All,

I have recently joined the HIRF team of OKTAL-SE.

I have several questions concerning the document v0.6:

1- Normals : the format does not define normals for an unstructured
mesh. There is a normal group in the field "Structured Mesh" (refer to
p51) but this group does not exist for an unstructured mesh.
In fact, we need to define the normal vector for each vertex of a
face. The faces' normals are also needed in our simulations.
Is it possible to add this information in the definition of the AMELET
format ?
For instance, the coordinates of a normal of a node could be added in
the group node defined as below:
nodes = six dimensional dataset
x y z nx ny nz

with nx,ny,nz coordinates of the vertex normal.

The coordinates of a face's normal could be set in a "Normal
group" (dataset of 3 reals).

Moreover, could it be possible :

2- to add a reference of the 2 faces that define a given edge ?

3- to add a parameter (i.e a boolean) that indicates if a given edge
of a face shall be selected (or not) in the computation ?

4- to control the direction of an antenna (source) by a fixed point ?


Best Regards,

Grégory Moura
OKTAL-SE

[cyril giraudon]

> 1- Normals : the format does not define normals for an unstructured
> mesh. There is a normal group in the field "Structured Mesh" (refer to
> p51) but this group does not exist for an unstructured mesh.
> In fact, we need to define the normal vector for each vertex of a
> face. The faces' normals are also needed in our simulations.

In Amelet-HDF, faces are implicitly oriented thanks to the nodes
numbering of elementType.
The normal are computed with the right hand grip rule.
The Amelet-HDF doesn't say it, I will add a paragraph.

> Is it possible to add this information in the definition of the AMELET
> format ?
> For instance, the coordinates of a normal of a node could be added in
> the group node defined as below:
>                 nodes = six dimensional dataset
>                         x  y  z  nx  ny  nz
>
>                                 with nx,ny,nz coordinates of the vertex normal.
>
> The coordinates of a face's normal could be set in a "Normal
> group" (dataset of 3 reals).
>

How are node's normal computed ?
Is this information is deduced from the surrounding faces or normal
faces or
from another part of the mesh ?

If yes, the mesh generator decorates the mesh with secondary
information
because it knows the solver exploits it. Amelet-HDF can't store all
decoration
information for all mesh generation stratergy.

There are two way to solve this issue :
- The node's normal computation algorithm is used by the pre
converter :
Amelet-HDF file ---- pre converter ---> Solver native format file
- The second solution is to use the "/extensionType" concept in Amelet-
HDF, see chapter 16.

An extensionType could look like :

data.h5
|-- mesh
| `-- $gmesh1
| `-- $mesh1
| |-- nodes
| |-- elementTypes
| `-- elementNodes
`-- extensionType/
`-- nodeNormal/
`-- $normal-nodes-mesh1[@reference=/mesh/$gmesh1/$mesh1]
`-- normal
Where "data.h5:/extensionType/nodeNormal/$normal-nodes-mesh1/normal"
is a nb nodes rows dataset and trhee column containing nx, ny, ny of
your propasal.

> Moreover, could it be possible :
>
> 2- to add a reference of the 2 faces that define a given edge ?
>

This is the same issue as the preceding section.
This kind of data can be deduced from the mesh, and Amelet-HDF doesn't
store secondary data.
I think the best way is to insert the right code in the pre converter
of the solver that needs this data.

The preceding extensionType can also be extended to something like :
data.h5
|-- mesh
| `-- $gmesh1
| `-- $mesh1
| |-- nodes
| |-- elementTypes
| `-- elementNodes
`-- extensionType/
`-- nodeNormalAndEdge/
`-- $nono-edge-mesh1[@reference=/mesh/$gmesh1/$mesh1]
|-- edgeFromFace
`-- normal

Where 'edgeFomFace' defines edges from faces.

> 3- to add a parameter (i.e a boolean) that indicates if a given edge
> of a face shall be selected (or not) in the computation ?

Sorry I don't understand, can you explain the use of this
information ?

>
> 4- to control the direction of an antenna (source) by a fixed point ?

The "/localizationSystem" paradigm aims at rotating, translating,
scaling
object in the space.
A link between an antenna and a localizationSystem allows to orient
properly
a antenna toward a direction.

Controlling the direction of an antenna (source) by a fixed point seem
to make
the asumption the radiation pattern has a revolution symmetry around
the axis
[antenna, fixed point].
This seems too restrictive to be added in Amelet-HDF.

I hope this helps you.

Best regards

Cyril Giraudon.

[Grégory Moura]

Dear Cyril,

Thank you for your answers. Here are my remarks.

1- I agree that there are two options:
- Either nodes' normals are inputs of several modules. In
that case, the computation of these normals can be performed during
the creation of the AMELET-HDF file. Then, your second solution (i.e.
to use the "/extensionType" concept) should be chosen.
- Or our module is the only one that uses nodes' normals. In
that case, your first option (i.e. the wrapper is in charge of the
calculation of normals) is the best one. As the computation of nodes'
normals is optional, a Boolean should be added in the AMELET format in
order to inform our module of the user's choice.

2- Same options as above.

3- We think it could be relevant to remove some edges of a given
element in the diffraction 's calculation. Indeed, during the creation
of a model, some “extra” edges may have been added (defaults).
Therefore, the user shall be able to select the edges that generate
diffractions (by default, all edges are selected).

4- I think we are not in line. In fact, i wanted to know whether it
could be possible to set (optionally) the direction of an antenna by a
point of an element of the scene. If this element is a mobile, the
motion of this element could control the direction of the antenna.

Best Regards

Grégory Moura

[cyril giraudon]

Dear Grégory,

>
> 1- I agree that there are two options:
>          - Either nodes' normals are inputs of several modules. In
> that case, the computation of these normals can be performed during
> the creation of the AMELET-HDF file. Then, your second solution (i.e.
> to use the "/extensionType" concept) should be chosen.
>          - Or our module is the only one that uses nodes' normals. In
> that case, your first option (i.e. the wrapper is in charge of the
> calculation of normals) is the best one. As the computation of nodes'
> normals is optional, a Boolean should be added in the AMELET format in
> order to inform our module of the user's choice.

OK

>
> 2- Same options as above.

OK

>
> 3- We think it could be relevant to remove some edges of a given
> element in the diffraction 's calculation. Indeed, during the creation
> of a model, some “extra” edges may have been added (defaults).
> Therefore, the user shall be able to select the edges that generate
> diffractions (by default, all edges are selected).

If I understand the need, the selection of the removed edges is
performed
in the creation model tool. So you can group those edges in mesh
group.

data.h5
`-- mesh
`-- $gmesh
`-- $a_mesh

|-- nodes
|-- elementTypes
|-- elementNodes

`-- group
`-- $removed_edges

Then you define a label 'removed_edges' or 'unused_edges' in
the label category :

data.h5
|-- label
| `-- $a_label_list
`-- mesh
`-- $gmesh
`-- $a_mesh

|-- nodes
|-- elementTypes
|-- elementNodes

`-- group
`-- $removed_edges

with 'data.h5:/label/a_label_list :
+------------------------------+
| removed_edges |
+------------------------------+

Finally a '/link' can be created to build a comprehensive
instruction :

data.h5
|-- link
| `-- $glink
| `-- $removed_edges[@subject=/label/$a_label_list
| @subject_id=0
| @object=/mesh/$gmesh/$a_mesh/
group/$removed_edges]
|-- label
| `-- $a_label_list
`-- mesh
`-- $gmesh
`-- $a_mesh

|-- nodes
|-- elementTypes
|-- elementNodes

`-- group
`-- $removed_edges

with the 'data.h5:/label/a_label_list string dataset :
+------------------------------+
| removed_edges |
+------------------------------+

>
> 4- I think we are not in line. In fact, i wanted to know whether it
> could be possible to set (optionally) the direction of an antenna by a
> point of an element of the scene. If this element is a mobile, the
> motion of this element could control the direction of the antenna.
>

I m'afraid it is not possible currently.
Could you propose a solution you would like to see in Amelet-HDF ?


Best Regards

Cyril