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

Issue 920 dimensional interp #1028

Merged
merged 11 commits into from
May 29, 2020
Merged

Issue 920 dimensional interp #1028

merged 11 commits into from
May 29, 2020

Conversation

rtimms
Copy link
Contributor

@rtimms rtimms commented May 28, 2020

Description

Calls to ProcessedVariable objects are made using dimensional time and space

Fixes #920

Type of change

Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #) - note reverse order of PR #s. If necessary, also add to the list of breaking changes.

  • New feature (non-breaking change which adds functionality)
  • Optimization (back-end change that speeds up the code)
  • Bug fix (non-breaking change which fixes an issue)

Key checklist:

  • No style issues: $ flake8
  • All tests pass: $ python run-tests.py --unit
  • The documentation builds: $ cd docs and then $ make clean; make html

You can run all three at once, using $ python run-tests.py --quick.

Further checks:

  • Code is commented, particularly in hard-to-understand areas
  • Tests added that prove fix is effective or that feature works

Copy link
Member

@valentinsulzer valentinsulzer left a comment

Choose a reason for hiding this comment

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

Thanks very much for doing this @rtimms ! Some comments here are requested changes and some are just comments for discussion

Clearly there are a few different ways of accessing the time variable. I think the recommended way should be sol["Time [s]"].entries

@@ -85,15 +85,16 @@
xnsurf = sol["X-averaged negative particle surface concentration"]
time = sol["Time [h]"]
# Coulomb counting
time_hours = time(sol.t)
time_secs = sol.t * model.timescale_eval
Copy link
Member

Choose a reason for hiding this comment

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

maybe do sol["Time [s]"].entries to avoid having to call model.timescale_eval?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

agreed that the recommended way should be sol["Time [s]"].entries. I've made this consistent everywhere (I think)

except AttributeError:
if self.warn:
pybamm.logger.warning("No timescale provided. Using default of 1 [s]")
self.timescale = 1
Copy link
Member

Choose a reason for hiding this comment

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

A model should always have a timescale, since the base model has the default timescale of 1s

Copy link
Contributor Author

@rtimms rtimms May 29, 2020

Choose a reason for hiding this comment

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

there is a bit of an issue with the shape when the timescale depends on the inputs. In base_solver the timescale is evaluated with the initial inputs. if you then try to do model.timescale.evaluate(inputs=solution.inputs) in ProcessedVariable then the entries of inputs are now of length t. For now I've done a try/except with using timescale_eval and then evaluating if that isn't found. Another option would be to store the initial values of the inputs in the solution and use that (since the timescale should be the same for all times). Or to go through inputs and only use the first entry.

Not sure what the best approach is. Thoughts?

Copy link
Member

Choose a reason for hiding this comment

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

I think the safest option is to not allow the timescale to depend on inputs. i.e. do model.timescale.evaluate() instead of model.timescale.evaluate(inputs=solution.inputs) (and use a try except for a clear error message). Allowing the timescale to change in e.g. parameter fitting runs is probably asking for trouble

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah I agree. I've added a check for this in base_solver

self.spatial_vars = {}
if solution.model:
for var in ["x", "y", "z", "r_n", "r_p"]:
if var and var + " [m]" in solution.model.variables:
Copy link
Member

Choose a reason for hiding this comment

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

this doesn't check that both var and var + " [m]" are in solution.model.variables. It just checks that var is not None or False, and that var + " [m]" is in solution.model.variables. You have to check both separately.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks!

elif self.base_variable.is_constant():
t = self.t_sol[0]
t = self.t_sol[0] * self.timescale
Copy link
Member

Choose a reason for hiding this comment

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

Am wondering whether t_sol should be stored in seconds. I guess you are either consistent with sol.t, or consistent with first_dim_pts, but you can't have both

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I went back and forth on this. I've added an attribute t_pts which is dimensional time. That way things ending _sol are the dimensionless values and things ending _pts are dimensional (and are the values used in the interpolant)

Copy link
Member

Choose a reason for hiding this comment

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

Great, that makes sense!

"Using default of 1 [m]".format(name)
)
scale = 1
return scale
Copy link
Member

Choose a reason for hiding this comment

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

maybe models should have a r_scale, x_scale, etc in the same way that they have a timescale. Probably a separate issue though. It would simplify processed variables and quickplot a lot.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah this would definitely be the neatest solution. I've made a new issue for this.

processed_var = pybamm.ProcessedVariable(var_sol, pybamm.Solution(t_sol, y_sol))
processed_var = pybamm.ProcessedVariable(
var_sol, pybamm.Solution(t_sol, y_sol), warn=False
)
Copy link
Member

Choose a reason for hiding this comment

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

Oh, I see, solution doesn't have a model here for timescale. Maybe Solution.model could be initialized to BaseModel?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yep, this worked thanks!

Copy link
Member

@valentinsulzer valentinsulzer left a comment

Choose a reason for hiding this comment

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

Happy with this now, thanks!

@rtimms rtimms merged commit 3472af2 into develop May 29, 2020
@rtimms rtimms deleted the issue-920-dimensional-interp branch May 29, 2020 16:24
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.

Make t and x dimensional in interpolation
2 participants