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

feat: local detuning validation for ahs #244

Merged
merged 14 commits into from
Apr 16, 2024
Merged

feat: local detuning validation for ahs #244

merged 14 commits into from
Apr 16, 2024

Conversation

AbeCoull
Copy link
Contributor

Issue #, if available:

Description of changes:

Testing done:

Merge Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.

General

Tests

  • I have added tests that prove my fix is effective or that my feature works (if appropriate)
  • I have checked that my tests are not configured for a specific region or account (if appropriate)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@AbeCoull AbeCoull requested a review from a team as a code owner April 11, 2024 22:37
Copy link

codecov bot commented Apr 11, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (3915b30) to head (499bba3).

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #244   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           48        48           
  Lines         3665      3702   +37     
  Branches       878       888   +10     
=========================================
+ Hits          3665      3702   +37     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

maolinml
maolinml previously approved these changes Apr 12, 2024
rchilaka-amzn
rchilaka-amzn previously approved these changes Apr 12, 2024
# If there is local detuning, the net value of detuning for each atom
# should not exceed a certain value
@root_validator(pre=True, skip_on_failure=True)
def net_detuning_must_not_exceed_max_net_detuning(cls, values):
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we split this function? Also, let's discuss more on this offline.

Copy link
Contributor

Choose a reason for hiding this comment

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

Few questions we discussed offline and we might need confirmation from the science team on these:

  1. Where to cross-verify those schema values, trying to understand what does these detuning patterns, magnitude mean?

Comment on lines +61 to +63
if not len(local_detuning):
return values

Copy link
Contributor

Choose a reason for hiding this comment

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

  1. if there are no local detuning why are we are returning values are we supposed to return an error or warning if this is specific for local detuning?

Comment on lines 87 to 89
# Get the contributions from local detuning at the time point
for detuning_pattern, shift_coef in zip(detuning_patterns, shift_coefs):
detuning_to_check += shift_coef[time_ind] * float(detuning_pattern[atom_index])
Copy link
Contributor

@virajvchaudhari virajvchaudhari Apr 15, 2024

Choose a reason for hiding this comment

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

  1. The method name says its checking if the net values doesn't exceed the max detuning value, but it retrieving the contributions, I need a bit more context on this to understand why this is part of this method.
    And similarly, for # Merge the time points for different shifting terms and detuning term

f"[{-capabilities.MAX_NET_DETUNING}, {capabilities.MAX_NET_DETUNING}]."
f"Numerical instabilities may occur during simulation."
)
return values
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we require this return?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, I did some tests, and yes, this return is necessary. The idea is that we want to raise a warning immediately once we found an atom has net detuning larger than the allowed value, and stop the validator for the net detuning. If we don't have this return, the unit test will fail.

An alternative approach is to break the for loop like we did in this validator

Comment on lines 82 to 111
for time_ind, time in enumerate(time_points):

# Get the contributions from all the global detunings
# (there could be multiple global driving fields) at the time point
values_global_detuning = sum(
[detuning_coef[time_ind] for detuning_coef in detuning_coefs]
)

for atom_index in range(len(detuning_patterns[0])):
# Get the contributions from local detuning at the time point
values_local_detuning = sum(
[
shift_coef[time_ind] * float(detuning_pattern[atom_index])
for detuning_pattern, shift_coef in zip(detuning_patterns, shift_coefs)
]
)

# The net detuning is the sum of both the global and local detunings
detuning_to_check = np.real(values_local_detuning + values_global_detuning)

# Issue a warning if the absolute value of the net detuning is
# beyond MAX_NET_DETUNING
if abs(detuning_to_check) > capabilities.MAX_NET_DETUNING:
warnings.warn(
f"Atom {atom_index} has net detuning {detuning_to_check} rad/s "
f"at time {time} seconds, which is outside the typical range "
f"[{-capabilities.MAX_NET_DETUNING}, {capabilities.MAX_NET_DETUNING}]."
f"Numerical instabilities may occur during simulation."
)
return values
Copy link
Contributor

Choose a reason for hiding this comment

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

It still seems like this could be function of its own, but should be fine.

Copy link
Contributor

Choose a reason for hiding this comment

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

Do you mean we have a function to check the validity of atom i at time point j, and then call that function in the for loop: for atom_index ...?

Comment on lines 27 to 34
def _check_threshold(
values,
time_points,
global_detuning_coefs,
local_detuning_patterns,
local_detuning_coefs,
capabilities,
):
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing docstring and type info, similar to this, if this belong in the helper file let's move it there.

@@ -36,3 +44,63 @@ def validate_value_range_with_warning(
f"[{min_value}, {max_value}]. The values should be specified in SI units."
)
break # Only one warning messasge will be issued


def validate_net_detuning_with_warning(
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Do we need this to be public?

Copy link
Contributor

Choose a reason for hiding this comment

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

No, but given that the previous function validate_value_range_with_warning is public, I figured that we want to be consistent here. Should I change both to private functions or can I keep them like that?

Copy link
Contributor

Choose a reason for hiding this comment

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

Sure, let's keep it like that, we can change to private if necessary.

@AbeCoull AbeCoull merged commit 9e872f0 into main Apr 16, 2024
33 checks passed
@AbeCoull AbeCoull deleted the local_valid branch April 16, 2024 01:16
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.

4 participants