Skip to content

Conversation

@jlnav
Copy link
Member

@jlnav jlnav commented Dec 11, 2019

The Timer module now measures in milliseconds behind-the-scenes. libE_stats displays additional millisecond values for Start and End times:

Start: 2019-12-11 10:27:50.227 End: 2019-12-11 10:27:50.733

However, for compatibility with current timing mechanisms timer.elapsed and timer.total times are returned as seconds. If necessary, I can implement additional settings or parameters for milliseconds if we want to be more precise throughout the project.

@jlnav jlnav requested review from jmlarson1 and shuds13 December 11, 2019 18:51
@coveralls
Copy link
Collaborator

coveralls commented Dec 11, 2019

Coverage Status

Coverage decreased (-0.04%) to 94.692% when pulling 867580c on feature/subsecond_time into 1bdf010 on develop.

@jmlarson1
Copy link
Member

@jlnav Is it possible to replace the two uses of time with datetime? For example, using datetime.strftime and time_tuple which should be like time.localtime(), see:
https://docs.python.org/3/library/datetime.html#datetime.date.timetuple

Thoughts?

@jlnav
Copy link
Member Author

jlnav commented Dec 11, 2019

@jlnav Is it possible to replace the two uses of time with datetime? For example, using datetime.strftime and time_tuple which should be like time.localtime(), see:
https://docs.python.org/3/library/datetime.html#datetime.date.timetuple

Thoughts?

Good point. Fixed.

@jmlarson1
Copy link
Member

I don't think this is working as expected. When I run, I get the following output:

Worker     2: Calc     0: sim Time: 0.00 Start: 2019-12-11 00:00:00.405 End: 2019-12-11 00:00:00.406 Status: Not set
Worker     3: Calc     0: sim Time: 0.00 Start: 2019-12-11 00:00:00.406 End: 2019-12-11 00:00:00.406 Status: Not set
Worker     3: Calc     1: sim Time: 0.00 Start: 2019-12-11 00:00:00.409 End: 2019-12-11 00:00:00.409 Status: Not set
Worker     2: Calc     1: sim Time: 0.00 Start: 2019-12-11 00:00:00.408 End: 2019-12-11 00:00:00.408 Status: Not set
...
...

The time is not correct, and the Status is Not Set for some reason.

@shuds13
Copy link
Member

shuds13 commented Dec 11, 2019

It will be Not Set unless you are using the calc_status feature. I may be inclined to only write the milliseconds to file if run-times are smaller than some cut-off, as these lines can get very long - esp. if you include job run-times (as well as calc times).

@shuds13
Copy link
Member

shuds13 commented Dec 11, 2019

I'm also getting milliseconds only on my laptop (running forces test).

@jlnav
Copy link
Member Author

jlnav commented Dec 11, 2019

Sorry about that. I think I just fixed the milliseconds-only issue.

@shuds13
Copy link
Member

shuds13 commented Dec 11, 2019

Yes, the time issue seems to be fixed now.

Copy link
Member

@shuds13 shuds13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to pull this into develop. We may want to think about variable precision to output, maybe depending on runtimes. But that can be an optional follow up.

@shuds13 shuds13 merged commit e111e68 into develop Dec 11, 2019
@jlnav jlnav mentioned this pull request Dec 12, 2019
@jlnav jlnav deleted the feature/subsecond_time branch December 17, 2019 19:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants