Double definition in typedef.h
Elizabeth Tasker
I noticed in typedef.h, there seems to be a duplicate definition for
field type number:
Emissivity0 = 37,
gParticlePosition = 37,
... that's bad right?
Elizabeth
Geoffrey So
From
Elizabeth
--
You received this message because you are subscribed to the Google Groups "enzo-dev" group.
To post to this group, send email to enzo...@googlegroups.com.
To unsubscribe from this group, send email to enzo-dev+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/enzo-dev?hl=en.
Matthew Turk
ago. Shouldn't be a problem unless both are on simultaneously, which
I think is not possible. The gParticleStuff fields are (as noted in
the file) pseudo-fields used by the FieldArray routines, which I think
are not currently in use; so, unless you are both using the field
array accessing of the particle positions *and* using the FLD solver
*and* expect both to work and not get confused between the two, you're
okay.
I am disinclined to suggest we go about incrementing all of the fields
with number > 37, however, since that would break IO in a
spectacularly unfortunate way. I would suggest we just cordon off the
problem area and assume (quite reasonably) that the timescale of this
actually causing a problem is longer than the timescale of an overhaul
in the IO system to use string identifiers rather than field numbers.
-Matt
Nathan Goldbaum
Matthew Turk
On Thu, Feb 9, 2012 at 9:24 PM, Nathan Goldbaum <natha...@gmail.com> wrote:
> It looks like the only place gParticlePosition is referenced is in
> Grid_CreateFieldArray.C, which defines several grid member functions that
> are never referenced anywhere else in the code. I think this is safe as is
> so long as no one uses the CreateFieldArray functions in a simulation that
> also uses the FLD radiation solver.
>
> Side note: as a newcomer to enzo, it's cruft like this that makes it very
> hard to find my way around $ENZO_DIR/src/enzo.
Yes, this is understandable. There are a lot of source files, and not
all of them are meaningful, or their meanings have changed, or they
have IFDEFs and the like preventing them from being compiled. A few
of us have been trying to remove those that don't serve a purpose, or
whose purpose is no longer relevant -- makefiles, one-off files, etc.
The field array files are part of a push from many years ago to make
Enzo more modular, with access methods and the like, to allow for
analysis tools to be built out of Enzo. This effort seems to have
stalled (and the efforts from Britton and myself to integrate enzo
with analysis have been a bit of a different tactic) but the remnants
are still there.
Overhauling the infrastructure of Enzo, a large part of which is
removing cruft, is something that people have been working on. It's
not the fastest process in the world. Even when a task is done, like
the new-config that Mike Kuhlen managed to push through on and finish
up, it can be challenging to meet all of the various needs of
different users, developers, and so on, which can lead to length merge
processes. Integration and major overhauls stretch out in time,
largely because leaving behind people reduces community buy-in. (The
problem of getting a bandwagon full up after the major week-of-code
integration four years ago was not an easy one to solve, and there are
still several splinters off the original groups that merged back
then.)
We've had a number of conversations on this list about overhauling the
way Enzo performs certain aspects -- event loop, configuration, active
particles, problem types, and so on. But bringing them all together
is really proving challenging; the task of community buy-in, where a
set of individuals feels some degree of ownership over a piece of code
or a change to the code base, is at loggerheads with a small focused
development team. If a handful of us got together at Columbia and
rewrote some piece of Enzo that then required everyone who wanted to
use it to modify their configuration files, that would probably not be
an easy sell. But if we got fifty people in a room and tried to do
it, the work would be unmanageable and would never get done, or would
not get done to the highest standards. (And I don't know why, but for
some reason developing Enzo doesn't seem to get people as excited as
some other codes, like yt -- is it because the stakes are higher with
Enzo? Is it because C++ is less fun? Is it because yt has a smaller
community? Is it that it's easy to put off dirty work on the
supposition that something else is coming down the line?)
I've given this a lot of thought over the last couple months, as I
have been thinking about my own attempts to overhaul portions of Enzo.
I've come to kind of think that the tasks of infrastructure overhaul
and cruft removal need a driving organization, but Enzo does not
currently have the support structure in place to support that kind of
organization. And furthermore, it's not entirely clear to me that
with such an organization in place, we could continue the pace of
non-cruft and non-infrastructure development.
-Matt