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

 
 

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

Submitted by:  gianluca de santis <gianlucadesi>
Submitted on:  Mon 17 Feb 2014 11:59:23 AM UTC  
 
Category: CoreSeverity: 4 - Important
Item Group: Functionality errorStatus: Fixed
Privacy: PublicAssigned to: Benedict Verhegghe <bverheg>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project AdministratorIn charge of this item.
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

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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project Member

 

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

Attach File(s):
   
   
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
  • -unavailable- added by bverheg (Posted a comment)
  • -unavailable- added by gianlucadesi (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 24 Feb 2015 05:17:36 PM UTCbverhegOpen/ClosedOpen=>Closed
    Tue 18 Feb 2014 05:39:11 PM UTCbverhegStatusIn Progress=>Fixed
    Mon 17 Feb 2014 03:57:30 PM UTCbverhegCategoryNone=>Core
      Item GroupNone=>Functionality error
      StatusNone=>In Progress
      Assigned toNone=>bverheg
    Mon 17 Feb 2014 11:59:23 AM UTCgianlucadesiAttached File-=>Added fieds_convert.py, #30587

    Back to the top


    Powered by Savane 3.1-cleanup1