bugpyFormex - Bugs: bug #40690, extension of Mesh.connectedTo

 
 

bug #40690: extension of Mesh.connectedTo

Submitted by:  francesco <francio>
Submitted on:  Sun 24 Nov 2013 02:13:39 PM UTC  
 
Category: CoreSeverity: 3 - Normal
Item Group: Feature requestStatus: 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)

Fri 29 Nov 2013 12:13:15 PM UTC, comment #9:

it works fine. closing the bug

francesco <francio>
Project Member
Fri 29 Nov 2013 07:47:01 AM UTC, comment #8:

Commit 7f070d9 adds Mesh.adjacentTo
Ready for test

My test example below.

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
Fri 29 Nov 2013 07:35:33 AM UTC, comment #7:

Concerning the (not)adjacentTo and (not)connectedTo methods: I think it would be better if these returned a list of element numbers instead of a Mesh. Getting the Mesh from the list can easily be done, the inverse not so.

And it would help unifying all select methods.

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
Fri 29 Nov 2013 07:17:17 AM UTC, comment #6:

The frontWalk methods with maxval= set walked one step too far.
This is fixed in commit 38fac01.

I see no further problems. Breaking from the loops keeps p on
the last assigned value. Both connectivity walk as well as adjacency walk seem to work properly:

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
Mon 25 Nov 2013 12:44:17 AM UTC, comment #5:

in the previous comment the code was not indented properly, I am trying again

def frontWalk(self,startat=0,frontinc=1,partinc=1,maxval=-1):

pt=None
for p in self.front(startat=startat,frontinc=frontinc,partinc=partinc):
if maxval >= 0:
if p.max() > maxval:
break
pt=p
return pt

francesco <francio>
Project Member
Mon 25 Nov 2013 12:37:02 AM UTC, comment #4:

the use of frontwalk does not produce the same results of the adjacency (see attachment). I am not sure if it is a functionality error of frontWalk.

also frontwalk should be changed to something like this otherwise if the break occurs the value of p is not stored

pt=None
for p in self.front(startat=startat,\
frontinc=frontinc,partinc=partinc):
if maxval >= 0:
if p.max() > maxval:
break
pt=p
return pt

(file #29701)

francesco <francio>
Project Member
Sun 24 Nov 2013 07:16:09 PM UTC, comment #3:

If what you want is elements connected to a given set of other elements, there are two ways:

- do a single step frontwalk with the given set of elements as the start

- take the sum of the adjacency lists of the given elements, and then take the unique.

So, methods already exist. If we want to create a new method for these, we could probably call them adjacentTo ?

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
Sun 24 Nov 2013 06:25:38 PM UTC, comment #2:

I checked your suggestion which shoul be changed to

def connectedTo(self,entities,level=0):
if level == 0:
elems = self.elems
else:
elems,lo = self.elems.insertLevel(level)
return self.select(elems.connectedTo(entities),compact=False)

Though I realized that this will produce a different results of what I meant. in your case the method will find all elements connected to ENTITIES and I think the proposed solution should replace the current connectedTo. Actually teh method I suggested should be called something like connectedElementsBy because it will check all elements connected by level (points, edges or faces). I think the method I meant can call the method you suggested but rigth now I cannot picture how.
I suggest to include both methods for the moment as proposed, keeping in mind a future improvement

francesco <francio>
Project Member
Sun 24 Nov 2013 05:43:42 PM UTC, comment #1:

This is indeed a good idea, and consistent with other Mesh methods. But the level should default to 0 (connected to nodes).

Also, it should not use adjacency tables: for large models, adjacency tables as they are implemented now may take a lot of memory, making their use with very large models problematic.
Recently, we therefore added frontWalk directly on Connectivity tables, using Connectivity.conectedTo, which avoids adjacency tables.
Also recently, a Varray class was developed that will in future avoid the large memory usage of adjacency tables.

However, I think there is no need for adjacency tables here: they provide lists of neighbouring elements. What we want here is (I think) lists of elements connected to nodes, or edges, or faces. Thus, I think of an implementation like this:

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
Sun 24 Nov 2013 02:13:39 PM UTC, original submission:

Mesh.(not)connectedTo now can find only elemnts connected to a list of nodes. I suggest to change the method to allow to find connections at different levels using the Mesh.adjacency method

def connectedTo(self,entities,level=1, **kargs):
adj = self.adjacency(level=level)[entities]
adj = unique(adj[adj!=-1])
return self.select(adj,**kargs)

francesco <francio>
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 #29701:  testfront.py added by francio (2KiB - 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 francio (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
    Fri 29 Nov 2013 12:13:15 PM UTCfrancioStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Fri 29 Nov 2013 07:17:17 AM UTCbverhegStatusNone=>In Progress
      Assigned toNone=>bverheg
    Mon 25 Nov 2013 12:37:01 AM UTCfrancioAttached File-=>Added testfront.py, #29701
    Sun 24 Nov 2013 05:43:42 PM UTCbverhegCategoryNone=>Core
      StatusReady For Test=>None

    Back to the top


    Powered by Savane 3.1-cleanup1