Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta history generation - interval logging weird #1207

Closed
Puckfist opened this issue Jan 26, 2018 · 1 comment
Closed

Meta history generation - interval logging weird #1207

Puckfist opened this issue Jan 26, 2018 · 1 comment

Comments

@Puckfist
Copy link
Contributor

One would expect that using the history generation feature of the meta data source, an interval logging point should correctly do its interval logging as though it had been running through that period of time (disregarding the future). However, because of the logic in DataPointRT:savePointValue,

case DataPointVO.LoggingTypes.INTERVAL:
if (!backdated)
intervalSave(newValue);

and pointValue still being initialized to the current point value, interval logging doesn't really work. I noticed I could get this working by doing a few things,

DataPointRT

  1. Change initialize / terminate historical to care about the simulation timer,
    public void initializeHistorical() {
    if(timer != null) {
    pointValue = getPointValueBefore(timer.currentTimeMillis());
    initializeIntervalLogging(timer.currentTimeMillis(), false);
    } else {
    initializeIntervalLogging(0l, false);
    }
    }

    public void terminateHistorical() {
    terminateIntervalLogging();
    pointValue = valueCache.getLatestPointValue();
    timer = Common.timer;
    }

  2. Change initilizeIntervalLogging to correctly set the interval start time:
    intervalStartTime = timer == null ? Common.timer.currentTimeMillis() : timer.currentTimeMillis();

Meta edit dwr:
move initialize historical after the delete before code, fix up the generate data source's history

I am going to do the work to the Meta edit dwr as it is simply more correct that way, but it should behave the same until DataPointRT is modified

@Puckfist
Copy link
Contributor Author

I didn't set the timer back, because the timer is set in the constructor so it just didn't seem right. These points shouldn't be in the runtime manager or anything like that, so it shouldn't matter - these data point RT's are discarded when the historical run is done.

@terrypacker terrypacker added this to To Do in 3.3.1 Release Jan 31, 2018
3.3.1 Release automation moved this from To Do to Done Feb 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
3.3.1 Release
  
Done
Development

No branches or pull requests

1 participant