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

Model Event-Efficiency Statistic #54

Open
gonsie opened this issue Jul 21, 2015 · 2 comments
Open

Model Event-Efficiency Statistic #54

gonsie opened this issue Jul 21, 2015 · 2 comments

Comments

@gonsie
Copy link
Member

gonsie commented Jul 21, 2015

a statistic that calculates, on average, how many events are created per event processed. Can be used during model development to understand if a model has an unstable event population.

@carothersc-zz
Copy link
Member

Thanks Elsa!

I suspect it's just events scheduled / events processed except that each
rank could have its own value
and all ranks need to be at just slightly above 1 otherwise a rank will run
out of memory ...

If we output rank 0's value, we should be good by default ...but for
complex, unbalanced models, we
may need options for more detailed outputs across the ranks ...ideas ??

Thanks,
Chris

On Tue, Jul 21, 2015 at 3:00 PM, Elsa Gonsiorowski <notifications@github.com

wrote:

a statistic that calculates, on average, how many events are created per
event processed. Can be used during model development to understand if a
model has an unstable event population.


Reply to this email directly or view it on GitHub
https://github.com/carothersc/ROSS/issues/54.


Christopher D. Carothers

Director, Center for Computational Innovations
Professor, Department of Computer Science
Rensselaer Polytechnic Institute
110 8th Street
Troy, New York 12180-3590

e-mail: chris.carothers@gmail.com
web page: www.cs.rpi.edu/~chrisc http://www.cs.rpi.edu/%7Echrisc
phone: (518) 276-2930

fax: (518) 276-4033

@JohnPJenkins
Copy link

Is the intention to simply capture stats on how many tw_event_send's are being called per-event? If so, then a scheduled/processed stat would be misleading, as scheduled would include events that are eventually rolled back, which ends up tying the stat to ROSS efficiency.

Having ROSS efficiency per-LP would be a Good Thing (tm), though...

From: Chris Carothers <notifications@github.commailto:notifications@github.com>
Reply-To: carothersc/ROSS <reply@reply.github.commailto:reply@reply.github.com>
Date: Tuesday, July 21, 2015 at 3:31 PM
To: carothersc/ROSS <ROSS@noreply.github.commailto:ROSS@noreply.github.com>
Subject: Re: [ROSS] Model Event-Efficiency Statistic (#54)

Thanks Elsa!

I suspect it's just events scheduled / events processed except that each
rank could have its own value
and all ranks need to be at just slightly above 1 otherwise a rank will run
out of memory ...

If we output rank 0's value, we should be good by default ...but for
complex, unbalanced models, we
may need options for more detailed outputs across the ranks ...ideas ??

Thanks,
Chris

On Tue, Jul 21, 2015 at 3:00 PM, Elsa Gonsiorowski <notifications@github.commailto:notifications@github.com

wrote:

a statistic that calculates, on average, how many events are created per
event processed. Can be used during model development to understand if a
model has an unstable event population.


Reply to this email directly or view it on GitHub
https://github.com/carothersc/ROSS/issues/54.


Christopher D. Carothers

Director, Center for Computational Innovations
Professor, Department of Computer Science
Rensselaer Polytechnic Institute
110 8th Street
Troy, New York 12180-3590

e-mail: chris.carothers@gmail.commailto:chris.carothers@gmail.com
web page: www.cs.rpi.edu/~chrisc http://www.cs.rpi.edu/%7Echrisc
phone: (518) 276-2930

fax: (518) 276-4033


Reply to this email directly or view it on GitHubhttps://github.com/carothersc/ROSS/issues/54#issuecomment-123469271.

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

No branches or pull requests

3 participants