refactor(prt): deconflict naming, use enum for tracking level #2202
Conversation
There was a problem hiding this comment.
Enumerators are a great idea. My only question is where's the best place to define them. Ideally, the particle shouldn't have to know what kind of a domain it's being tracked though. (Hopefully that's true except for the new enumerators, but I'm not 100% sure to be honest.) Could they be defined in the relevant tracking methods? In addition to a desirable separation of concerns, this would also allow them to be customized for different kinds of tracking domains in the future, e.g., a stream discretized into reaches. Would be happy to chat if you think this is feasible and worth exploring
There was a problem hiding this comment.
Good point- agree that method is the better place to define domain level. Maybe instead of an enum, each level could then just be a constant defined in the corresponding base method type.
There was a problem hiding this comment.
I figure the particle module is a good place for the status and event enums though
There was a problem hiding this comment.
totally agree - the status and event enums are best kept in the particle module
There was a problem hiding this comment.
regarding domain levels - so each method type would have its level baked in, perhaps as a %level attribute, instead of hard-coded numbers? seems like that would work
|
This one can wait until after the release, since it sounds like we want to rethink where to define tracking level constants. Maybe introduce a base method type for each level, like we just did for cells in #2203? |
maybe that's a good approach - agree it can wait, and let's think on it some more. i'm generally wary of adding too many classes, but sometimes it just makes sense |
Particle[Store]Type%idomainhas nothing to do with discretization IDOMAIN, name ititrdomainfor "tracking domain" to clarify what we mean. Also use an enum for method tracking level.