> Another option is that when you provide the constraint... you provide the > constant (and it's stored in the constraint system). This isn't a bad idea... > and will probably use less storage.
That's what I was envisioning... As for the node bc ids, > Now the questions shifts to how to provide that constant. My recommendation > for now is to call a function that takes (x, y, z, t, boundary_id). The > problem is that nodes (and DOFs) don't have a boundary id. We could add > one... but then the question shifts to how to apply those boundary_id's. My > vote is that during equation_system_init() / reinit() we read the BoundaryInfo > object on the mesh and apply the boundary_id of any face to all of it's nodes. > That way boundary id's are automatically propagated from "sidesets" after > adaptivity. Trying to "prolong" nodesets is a bad bad bad... I can get into > why if anyone is interested. Let me just say that I've been there... and it's > not good. > > What do you think? > > Can we pay the price of putting an unsigned int on every node? What if instead after each refinement/coarsening you (i) clear a node list, and then loop over active elements & their faces to build up a derived node bc list? You regenerate it instead of trying to prolong nodes... -Ben ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
