bugpyFormex - Bugs: bug #37586, behavior of Prop() in...

 
 

bug #37586: behavior of Prop() in plugins/properties.py

Submitted by:  Wouter Devriendt <whdvrien>
Submitted on:  Wed 17 Oct 2012 09:49:54 AM UTC  
 
Category: PluginsSeverity: 3 - Normal
Item Group: Functionality errorStatus: Wont Fix
Privacy: PublicAssigned to: None
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

Wed 17 Oct 2012 11:27:42 AM UTC, comment #1:

The proposed solution is valuable for the presented case, but risks to have far-reaching consequences. The unique() actually performs 3 things:
- create a 1D array out of the data
- sort the data
- make sure the data are unique
We could leave out the sorting, in some case also the uniqueness,
but certainly not the array creation.

When designing the property database, it was the intention that properties would be constant data valid for all the items in the specified set. Re-ordering of the items in the set is therefore no problem. It is also a lot cleaner in the output if the items come out sorted.

Adding a 'sort=True' argument (and then possibly also a 'unique=True') would clutter up the Prop interface, where we want to keep the number of predefined keys as small as possible. And it would probably make it confusing to the user as to when to use them.

An alternative would be to renumber the data according to the
results of unique. That would also require an extra field and be confusing.

So I suggest to leave it like it is for now, and explain to the
user that when he provides data that are not constant for all the elements in set, he should first uniquize the set (and his data) before entering them in the property database.

Furthermore I think it is best to concentrate on constant properties for all items in the set. Thus the case of surface
labels could be handled by grouping the elements per label and specifying a separate property record for each of the labels, with the proper subset of the elements.
In a large model with n elements, six subsets with a constant label would much more efficient than a list of n labels.

We should however envision the possibility of data that are continuously changing over the elements. For such cases we should probably create some kind of Field class. A Field class
would then hold data in a way that is only influenced by the number of the elements, not by their order.

I am leaving this bug open until we decide how to proceed.

Benedict Verhegghe <bverheg>
Project Administrator
Wed 17 Oct 2012 09:49:54 AM UTC, original submission:

The definition of a surface in a propertyDB sorts the elements, while the labels are not sorted, changing the labels for each element.

Example:

returns:

[...], 'set': array([1, 2]), [...], 'label': ['S2', 'S1'], [...]

It would be useful to add a sort Boolean to the Prop definition:

Wouter Devriendt <whdvrien>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

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 whdvrien (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 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 07 Nov 2013 02:49:59 PM UTCbverhegOpen/ClosedOpen=>Closed
    Wed 17 Oct 2012 11:27:42 AM UTCbverhegStatusNone=>Wont Fix

    Back to the top


    Powered by Savane 3.1-cleanup1