Firstly, we heavily use this option - we _never_ renumber (when possible - it's not possible with ParallelMesh for instance).

Secondly: Please, for the love of god, can we get rid of this being a double negative?

I vote for:

MeshBase::allowNodeAndElemRenumbering(bool)

Or the like...

Derek

On Tue, Oct 16, 2012 at 7:43 AM, Roy Stogner <roystgnr@ices.utexas.edu> wrote:

We currently have only one way to tell a mesh not to do renumbering:
pass in "true" to MeshBase::prepare_for_use().  Would it be reasonable
to replace this API with a direct public accessor for
MeshBase::_skip_renumber...?  That way users would be able to control
renumbering even when the method calling prepare_for_use() has no way
to know a priori whether renumbering is desireable or not.

The new API could either be made
(1) simple (take away the argument to prepare_for_use(), callers can
use the accessor instead)
(2) backwards-compatible (prepare_for_use() still takes an argument,
and then renumbering is skipped if either the argument or the initial
_skip state is true)
(3) backwards-compatible with behavior (2) at first, but increasingly
simple (the argument is eventually libmesh_deprecated(), then removed)
after a release or two.

My inclination is towards (3) but I could be talked into (1) if
nobody's directly using that argument (outside library code).

Thoughts, preferences?
---
Roy

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel