Closed mvernacc closed 5 years ago
Do you have a MWE? It's going to be hard to understand what is going on without this. Or can you send us the links to the repos and the commits you were using so we can reproduce the error?
I want to understand why this is happening before making a change, instead of hacking it.
Do you have a MWE? It's going to be hard to understand what is going on without this. Or can you send us the links to the repos and the commits you were using so we can reproduce the error?
I am working on making a minimum working example
Here is the example: https://gist.github.com/mvernacc/5505ea8278f8cacff9ce0b2d447ccf1c It turns out the issue is specifically with comparing a variable dimensioned in radians to a dimensionless number.
This really is an edge case, and I'm tempted to say that this is somewhat an issue on the part of pint. It allows you to make the comparison:
units('') <= units('radians')
whereas I think you shouldn't be able to. (Tbh I have always been frustrated with pint's handling of dimless variables, since floats do not have a .magnitude, and writing exceptions is a pain.) Let me see what we can do. Thanks for the MWE!
Ok, thanks for looking into it.
Perhaps the underlying problem is that I decided to make some of my angles dim'less because I need to do taylor series on them to approximate trig functions. I had left off the units because I though pint would throw a fit about rad + rad**2 + rad**3 + ...
.
But it turns out that with pint ureg('rad') == ureg('rad**2')
!?!?
So I can dimension all my angles with radians and that should solve the problem...
The funny thing is that sin(radians) returns a ratio of lengths (dimless). If you think about it, a radian is a ratio of lengths (diameter/circumference of radius). And so, I think it's fine if you just do the Taylor expansion without dimensions as intended.
(yes, I am suggesting here is that the 'unit' radians is tautological.)
If you don't mind, I am going to close this issue since this is definitely a pint problem. I do suggest bringing it up with pint, I'm sure they would appreciate the MWEs and help with fixes.
I just updated gpkit and am now having an AttributeError from a model that used to run ok. The error comes from
Tight.process_result
trying to do a pint unit conversion on a variable that is of typenumpy.float64
, not a pint type. I think I have found a solution to the error.Error
Context
This model was previously running without this error when I was using gpkit v0.7. This morning I upgraded to the latest gpkit v0.8 by
git pull
,pip install -e .
. Now I get this error when a particular constrain goes un-tight. In some contexts the model solves without raising this error; I believe this is because the constraints all remain tightSolution
I changed line 54 of tight.py to:
and the error does not occur.
Suspected cause
I think that I have a constraint which is comparing a dimensionless pint variable to a float variable. Line 54 only checked that
leftsubbed
was pint-like before calling pint methods on bothleftsubbed
andrightsubbed
.