-
Notifications
You must be signed in to change notification settings - Fork 37
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
Workshop March 2022 Examples #139
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pulled your branch locally and tried to run the test to make sure it runs on a Windows machine. It failed for two reasons:
- GLPK can only be run serially, there is no "threads" option.
- Specifying 10 for is too many cores for my machine (max 8).
Commenting out the "threads" option and specifying 6 for <parallel>
allowed the test to run successfully for my setup. I think the fixes for these two issues are pretty simple to implement and will ensure that the test runs on Windows.
src/dispatch/pyomo_dispatch.py
Outdated
@@ -303,7 +303,8 @@ def dispatch_window(self, time, time_offset, | |||
attempts += 1 | |||
print(f'DEBUGG solve attempt {attempts} ...:') | |||
# solve | |||
soln = pyo.SolverFactory(self._solver).solve(m) | |||
solve_options = {'threads': 2} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting "threads" does not work for GLPK. The options passed into "solve" appear to be specific to the solver used. I'm sure this is an option for CBC, but it throws an error when using GLPK. I don't know what the behavior is if other solvers are used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting; I don't recall adding this line; I must have been experimenting with something I didn't finalize. I can remove this. Philosophically I think it should only be set based on user requests specific to individual solvers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think perhaps there are pieces of your top comment above that aren't showing. I think you have to escape XML nodes as <example>
(using backticks "`") otherwise they get treated as formatting tags such as "" (no backticks).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, forgot the backticks on that one. Preview function is your friend.
# for now, outer does not use InternalParallel | ||
batchSize = run_info.find('batchSize') | ||
batchSize.text = f'{case.outerParallel}' | ||
if case.innerParallel: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the comment on os.cpu_count()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hopefully the check I added will catch this, let me know if you think anything further should be done
templates/template_driver.py
Outdated
sampler = 'grid' | ||
else: | ||
sampler = 'opt' | ||
print() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Empty print statement can be deleted.
# parallel | ||
if case.innerParallel: | ||
run_info.append(xmlUtils.newNode('internalParallel', text='True')) | ||
run_info.find('batchSize').text = f'{case.innerParallel}' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the comment on os.cpu_count().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same, let me know if you think anything more needs doing
src/Cases.py
Outdated
parallel = InputData.parameterInputFactory('parallel', descr=r"""Describes how to parallelize this run.""") | ||
parallel.addSub(InputData.parameterInputFactory('outer', contentType=InputTypes.IntegerType, | ||
descr=r"""the number of parallel runs to use for the outer optimization run. The product of this | ||
number and \xmlNode{inner} should be at most the number of parallel process availabe on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"available"
templates/template_driver.py
Outdated
@@ -68,7 +68,7 @@ class Template(TemplateBase, Base): | |||
|
|||
var_template = xmlUtils.newNode('variable') | |||
var_template.append(xmlUtils.newNode('distribution')) | |||
var_template.append(xmlUtils.newNode('grid', attrib={'type':'value', 'construction':'custom'})) | |||
#var_template.append(xmlUtils.newNode('grid', attrib={'type':'value', 'construction':'custom'})) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This appears to be commented out, does it need to stay or can it be deleted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed
if sub.getName() == 'outer': | ||
self.outerParallel = sub.value | ||
elif sub.getName() == 'inner': | ||
self.innerParallel = sub.value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried running the htse test case and an error was thrown because more cores were requested than available (my Windows machine has 8). I think it would be a good idea to check the number of available cores using "os.cpu_count()" and make sure that the user specified number is not greater than the maximum number available or some threshold. Generally, I try to only use max os.cpu_count() -1 cores so that it doesn't lock up my machine. Probably should add a debug or warning message if the user specifies too many cores and the number is adjusted downward to allow the case to run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good thought. That check won't work well when we're running on HPC, but we can follow up with that in a future PR where we auto-handle HPC stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the automated tests are failing and I think I know why. A quick fix and a comment to consider.
# check to see if the number of processes available can meet the request | ||
detected = os.cpu_count() - 1 # -1 to prevent machine OS locking up | ||
if detected < cores_requested: | ||
self.raiseAWarning('System may be overloaded and greatly increase run time! ' + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a comment for consideration:
On my Windows machine, requesting more cores than you have available results in an error and RAVEN will not run, not sure what the behavior is on Mac or Linux. We could raise an error here or raise a warning and wait for RAVEN to throw an error later, either way is probably fine. I think the important thing is to inform the user that they requested more cores than the machine has available. If that particular error is thrown later, the user will have an idea as to why the simulations were not run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I don't love how this is handled generally speaking; I think handling it better in RAVEN may lead to sensible error messages so we don't duplicate that effort in HERON.
@@ -303,7 +303,6 @@ def dispatch_window(self, time, time_offset, | |||
attempts += 1 | |||
print(f'DEBUGG solve attempt {attempts} ...:') | |||
# solve | |||
solve_options = {'threads': 2} | |||
soln = pyo.SolverFactory(self._solver).solve(m, options=solve_options) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure this is what is causing the automated tests to fail. Removing the options=solve_options
should fix this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whoops! fixed.
Pull Request Description
What issue does this change request address?
Initial steps towards #122
What are the significant changes in functionality due to this change request?
Adds example case(s) for users to try out while learning the code
Other modifications:
For Change Control Board: Change Request Review
The following review must be completed by an authorized member of the Change Control Board.