RFC: Change in behavior for pf.current_time in Enzo frontend
Hi all, Right now, amongst the confusing parameters available to an Enzo frontend parameter file, we have: pf["InitialTime"] pf.current_time These two are right now exactly the same. However, in most/all of the other frontends, pf.current_time is (or should be) the actual time in seconds. For Enzo this would mean multiplying by pf["seconds"]. Changing this could adversely affect many user scripts. However, not changing it means we continue with this confusing behavior. For instance, the TimeStamp callback is currently totally incorrect for Enzo, but completely correct for FLASH. Is this an important enough change to overcome the old behavior? Or should this be deferred to 3.0? [+-][01] -Matt
I am +1 for yt 3.0, but -1 on changing it for 2.x. The behavior of pf.current_time is in the core of a ton of my own analysis and my guess is that is true for many people. In my opinion, changes like this that are for the sake of making things more proper, but break with previous behavior, should only be made in big version jumps, where in some sense, all bets are off anyway. This change will also need to be propagated through to things like the SimulationTimeSeries. Britton On Thu, Nov 1, 2012 at 2:54 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
Right now, amongst the confusing parameters available to an Enzo frontend parameter file, we have:
pf["InitialTime"] pf.current_time
These two are right now exactly the same. However, in most/all of the other frontends, pf.current_time is (or should be) the actual time in seconds. For Enzo this would mean multiplying by pf["seconds"].
Changing this could adversely affect many user scripts. However, not changing it means we continue with this confusing behavior. For instance, the TimeStamp callback is currently totally incorrect for Enzo, but completely correct for FLASH.
Is this an important enough change to overcome the old behavior? Or should this be deferred to 3.0?
[+-][01]
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I agree wtih Britton. +1 for 3.0, -1 for 2.x j On Thu, Nov 1, 2012 at 3:12 PM, Britton Smith <brittonsmith@gmail.com>wrote:
I am +1 for yt 3.0, but -1 on changing it for 2.x. The behavior of pf.current_time is in the core of a ton of my own analysis and my guess is that is true for many people. In my opinion, changes like this that are for the sake of making things more proper, but break with previous behavior, should only be made in big version jumps, where in some sense, all bets are off anyway. This change will also need to be propagated through to things like the SimulationTimeSeries.
Britton
On Thu, Nov 1, 2012 at 2:54 PM, Matthew Turk <matthewturk@gmail.com>wrote:
Hi all,
Right now, amongst the confusing parameters available to an Enzo frontend parameter file, we have:
pf["InitialTime"] pf.current_time
These two are right now exactly the same. However, in most/all of the other frontends, pf.current_time is (or should be) the actual time in seconds. For Enzo this would mean multiplying by pf["seconds"].
Changing this could adversely affect many user scripts. However, not changing it means we continue with this confusing behavior. For instance, the TimeStamp callback is currently totally incorrect for Enzo, but completely correct for FLASH.
Is this an important enough change to overcome the old behavior? Or should this be deferred to 3.0?
[+-][01]
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Agreed with BS and JO. On Thu, Nov 1, 2012 at 12:34 PM, j s oishi <jsoishi@gmail.com> wrote:
I agree wtih Britton.
+1 for 3.0, -1 for 2.x
j
On Thu, Nov 1, 2012 at 3:12 PM, Britton Smith <brittonsmith@gmail.com>wrote:
I am +1 for yt 3.0, but -1 on changing it for 2.x. The behavior of pf.current_time is in the core of a ton of my own analysis and my guess is that is true for many people. In my opinion, changes like this that are for the sake of making things more proper, but break with previous behavior, should only be made in big version jumps, where in some sense, all bets are off anyway. This change will also need to be propagated through to things like the SimulationTimeSeries.
Britton
On Thu, Nov 1, 2012 at 2:54 PM, Matthew Turk <matthewturk@gmail.com>wrote:
Hi all,
Right now, amongst the confusing parameters available to an Enzo frontend parameter file, we have:
pf["InitialTime"] pf.current_time
These two are right now exactly the same. However, in most/all of the other frontends, pf.current_time is (or should be) the actual time in seconds. For Enzo this would mean multiplying by pf["seconds"].
Changing this could adversely affect many user scripts. However, not changing it means we continue with this confusing behavior. For instance, the TimeStamp callback is currently totally incorrect for Enzo, but completely correct for FLASH.
Is this an important enough change to overcome the old behavior? Or should this be deferred to 3.0?
[+-][01]
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Okay, seems like this is a pretty big change that we should wait on. But I definitely want to follow through on this with 3.0. (Related note: 3.0 should be usable for everything now that does not require covering grids.) On Thu, Nov 1, 2012 at 3:42 PM, Cameron Hummels <chummels@gmail.com> wrote:
Agreed with BS and JO.
On Thu, Nov 1, 2012 at 12:34 PM, j s oishi <jsoishi@gmail.com> wrote:
I agree wtih Britton.
+1 for 3.0, -1 for 2.x
j
On Thu, Nov 1, 2012 at 3:12 PM, Britton Smith <brittonsmith@gmail.com> wrote:
I am +1 for yt 3.0, but -1 on changing it for 2.x. The behavior of pf.current_time is in the core of a ton of my own analysis and my guess is that is true for many people. In my opinion, changes like this that are for the sake of making things more proper, but break with previous behavior, should only be made in big version jumps, where in some sense, all bets are off anyway. This change will also need to be propagated through to things like the SimulationTimeSeries.
Britton
On Thu, Nov 1, 2012 at 2:54 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
Right now, amongst the confusing parameters available to an Enzo frontend parameter file, we have:
pf["InitialTime"] pf.current_time
These two are right now exactly the same. However, in most/all of the other frontends, pf.current_time is (or should be) the actual time in seconds. For Enzo this would mean multiplying by pf["seconds"].
Changing this could adversely affect many user scripts. However, not changing it means we continue with this confusing behavior. For instance, the TimeStamp callback is currently totally incorrect for Enzo, but completely correct for FLASH.
Is this an important enough change to overcome the old behavior? Or should this be deferred to 3.0?
[+-][01]
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (4)
-
Britton Smith -
Cameron Hummels -
j s oishi -
Matthew Turk