bugpyFormex - Bugs: bug #41622, Fields.convert() needs to be fixed

 
 

bug #41622: Fields.convert() needs to be fixed

Submitter:  gianluca de santis <gianlucadesi>
Submitted:  Mon 17 Feb 2014 11:59:23 AM UTC
   
 
Category:  Core Severity:  4 - Important
Item Group:  Functionality error Status:  Fixed
Privacy:  Public Assigned to:  bverheg
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 24 Feb 2015 05:17:36 PM UTC, comment #6: 

I decided not to automatically add the fields after all.

Benedict Verhegghe <bverheg>
Group administrator
Thu 15 May 2014 06:31:56 PM UTC, comment #5: 

In 88ef0de, a fieldReport() function has been added to the Geometry class. That solves 2)

Re 1): I do not see a need to return the Field: you can just write


Field(mesh,'node',VAL).convert('elemc').data.reshape(-1)


The only difference is that in this case the fields are not stored inside the mesh. That raises the following questions:

1- Should we store Fields automatically in the Geometry they relate to?
2- Should we do so only for Fields that get a name given?
3- Should we automatically store converted Fields also?

and in case the answer to the last question is affirmative:
4- Should we overwrite the converted Field, or keep the old Field and create a new name?

My feeling now is to answer resp. Yes, Yes, No, Irrelevant.
But I would like to hear the idea of other devs/users.

I am leaving this bug open for a while, until decided.

Benedict Verhegghe <bverheg>
Group administrator
Wed 19 Feb 2014 10:53:40 AM UTC, comment #4: 

I have tested the new implementation on my cases (including read/write .pgf) and it works fine!

Two questions:

1) why geometry.addField() and geometry.convertField() do not have an explicit return unlike most pyFormex functions? This makes not possible to concatenate methods.

If an explicit return would be added, the deprecated method Mesh.nodalToElement(VAL) could be directly replaced by

self.addField(fldtype='node',data=VAL,fldname='nval').convertField(fldname='nval',totype='elemc',toname='eval').fields['eval'].data.reshape(-1)

and mesh_ext Mesh.elementToNodal(VAL) by
self.addField(fldtype='elemc',data=eval,fldname='eval').convertField(fldname='eval',totype='node',toname='nval').fields['nval'].data.reshape(-1)

2) to read the fields of a geometry G the user need to write:
utils.formatDict(G.fields)
Could we use something simpler like

print (G.fields)   ?

Also, it would be nice to give the fields info (without data) when printing a geometry:

print (G)

Mesh: 8 nodes, 3 elems, plexitude 4, ndim 2, eltype: quad4
  BBox: [ 0.  0.  0.], [ 1.  1.  0.]
  Size: [ 1.  1.  0.]
  nval = Field 'nval', type 'node', shape (8,)
  eval = Field 'eval', type 'elemc', shape (3,)

gianluca de santis <gianlucadesi>
Group Member
Tue 18 Feb 2014 05:39:11 PM UTC, comment #3: 

In aaa54d7, the Field class has been changed, oriented the components of vectorial data along the last axis.

This should fix the issue.

Benedict Verhegghe <bverheg>
Group administrator
Mon 17 Feb 2014 04:17:23 PM UTC, comment #2: 

Well, it looks like I messed up somewhere between my test examples and the implementation of the Field class. The docs of the Field class states that the FIRST axis is the components of the vector, unlike what I wrote in https://savannah.nongnu.org/bugs/index.php?41622#comment1.

After going through the code, I can understand why at some point I decided to turn it around, because some things are a bit easier to code if the vector components are the first axis. However, that leaves us with an inconsistency: 3D vector types in pyFormex (like Coords, and normals) have their components along the last axis. So a user might expect this to be the case for the Fields also. A Field might e.g. hold the deformex coordinates, or the displacements, and the user might be confused if he can not add these Fields with the Coords of his Geometry. Same for normals: computed normals would have to be transposed before adding them as Field variables.

So I suggest we change the Field implementation (up to now it has merely been used for scalar Fields, thus will not present a problem) to vectorial components along the LAST axis. It will need some more programming, and might be slightly less efficient when rendering scalar values from a vectorial Field, but I guess the user's comfort should be prevalent here.

Benedict Verhegghe <bverheg>
Group administrator
Mon 17 Feb 2014 03:57:30 PM UTC, comment #1: 

The Field conversions that require recursive calls are fixed in 2c149c6. This commit also adds a formatted printout of a Field.
To print all the fields of a Geometry G, you can use: print(utils.formatDict(G.fields))

The other changes suggested by the parent should not be needed. The nodalSum and repeat functions already take care of vectorial data. The point is that the field data should be constructed with the LAST axis as the components of the vector (just like a Coords).
Some of the conversions still need to be fixed for vectorial data though.

Benedict Verhegghe <bverheg>
Group administrator
Mon 17 Feb 2014 11:59:23 AM UTC, original submission:  

In commit 382bb89 the Mesh.nodalToElement has been deprecated in favour of Field class, available from Geometry.convertField().

On my cases Field.convert() does not fully work. In attachment a script including:

-a function to print all fields of a geometry object.

-an example to test the current Field.convert(), showing where it fails.

-a fixed version of Field.convert(). Using this version in field.py the test case works fine.

The fixed version of Field.convert() generalizes mesh_ext.elementToNodal() to vectors. So mesh_ext.elementToNodal() could then be deprecated.

gianluca de santis <gianlucadesi>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #30587:  fieds_convert.py added by gianlucadesi (4KiB - text/x-python)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bverheg (Posted a comment)
  • -email is unavailable- added by gianlucadesi (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-24 bverheg Open/ClosedOpen Closed
    2014-02-18 bverheg StatusIn Progress Fixed
    2014-02-17 bverheg CategoryNone Core
        Item GroupNone Functionality error
        StatusNone In Progress
        Assigned toNone bverheg
    2014-02-17 gianlucadesi Attached File- Added fieds_convert.py, #30587

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code