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
fix silenced unit conversion bugs #2897
fix silenced unit conversion bugs #2897
Conversation
So the error raised in
Which is happening for |
ee205cc
to
48a8e3b
Compare
I was able to track the error down to yt/yt/fields/vector_operations.py Line 172 in 5fb1bea
So in 2D, we apparently replace a velocity field with |
ok so I think I'm headed in the right direction.
Apparently this happens because update: indeed the problem is more general than this. The projection object in update2: the units of projected fields are actually conditional, see
so we only end up in this situation if there's no weight field. |
0391e3a
to
eb96cc3
Compare
yt/fields/field_info_container.py
Outdated
@@ -470,6 +471,8 @@ def check_derived_fields(self, fields_to_check=None): | |||
fi = self[field] | |||
try: | |||
fd = fi.get_dependencies(ds=self.ds) | |||
except UnitConversionError: |
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 have a suspicion that this is going to cause a lot of heartache. I do think it's the right thing to do.
One way we might make it an awful lot easier would be to make it much more obvious how to have the units deduced. As of right now, I don't think that's possible.
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.
One way we might make it an awful lot easier would be to make it much more obvious how to have the units deduced. As of right now, I don't think that's possible.
at what level ? within the code base or from the user perspective ?
5b6fcd5
to
d52efe8
Compare
I meant from user perspective, when adding a derived field.
…On Sat, Sep 12, 2020 at 3:51 PM Clément Robert ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In yt/fields/field_info_container.py
<#2897 (comment)>:
> @@ -470,6 +471,8 @@ def check_derived_fields(self, fields_to_check=None):
fi = self[field]
try:
fd = fi.get_dependencies(ds=self.ds)
+ except UnitConversionError:
One way we might make it an awful lot easier would be to make it much more
obvious how to have the units deduced. As of right now, I don't think
that's possible.
at what level ? within the code base or from the user perspective ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2897 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAVXO3MP4P5YB5LDXENRL3SFPNN3ANCNFSM4RJHORMA>
.
|
usually density is mass density, so this is right
…On Sat, Sep 12, 2020 at 4:31 PM Clément Robert ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In yt/data_objects/tests/test_center_squeeze.py
<#2897 (comment)>:
> @@ -6,7 +6,7 @@ def test_center_squeeze():
# create and test amr, random and particle data
check_single_ds(fake_amr_ds(fields=("Density",)))
- check_single_ds(fake_random_ds(16, fields=("Density",)))
+ check_single_ds(fake_random_ds(16, fields=("Density",), units=("g/cm**3",)))
@matthewturk <https://github.com/matthewturk> I think I made a mistake
here... "Density" is supposed to be a number density in "cm**(-3)", right
?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2897 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAVXO6WMRJVXF4MR5GAAMLSFPSDNANCNFSM4RJHORMA>
.
|
d52efe8
to
3a01fcf
Compare
Ok, I think this is back to a state where only answer tests on Travis, + maybe a handful of test on Jenkins should still fail. |
About the remaining failures on Jenkins: |
I'm also not sure how they end up dimensionless without that just being another error that's propagating to where we're seeing it. |
3a01fcf
to
e162507
Compare
Just rebased to run tests again. There's a actually a non-zero chance that the remaining bugs magically went away because a lot of the issues I was trying to address here were solved on the main branch already (by @cphyc !). 🤞🏻 |
Nope, the dimensionless -> cm issue still here. I hope we can discuss this in a future triage |
I think it's unlikely I'll ever manage to summon the will to fix this. Closing for now. |
PR Summary
Another bug discovered in #2851
Opening as a draft to expose the bug in CI before I apply the fix.
update:
Apparently the main issue is that
fake_random_ds
has a very fragile api: the kwargsfields
andunits
have default values but there is no mechanism to prevent using non-default fields without explicitly specifying their units. As a results we have a bunch of tests where we build a"temperature"
field with units"cm/s"
.These should now be fixed here, but I'm not fixing
fake_random_ds
's api as a whole for now (too much work for the time I have on my hands).A different error is revealed in
yt/data_objects/tests/test_covering_grid.py::test_smoothed_covering_grid_2d_dataset
, I'll try to investigate on this one.