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

DM-42285: Update to support numpy 1.25+ and various optimizations. #39

Merged
merged 8 commits into from Jan 11, 2024

Conversation

erykoff
Copy link
Collaborator

@erykoff erykoff commented Dec 20, 2023

This also updates to ensure that reverse indices are sorted. This is important to ensure reserved stars and such are consistent from system to system and numpy version to numpy version.

Upstream problem reported here: esheldon/esutil#87

Apparently this has been "loose" forever but it just happened to work okay until now.

Using this branch and numpy 1.24 the fgcmcal tests are 5% faster (and this is a lower limit on the speed improvement in larger dataset). Using this branch and numpy 1.26 the fgcmcal tests are another 5% faster still.

@@ -382,7 +382,7 @@ def computeCCDChromaticity(self):
self.fgcmLog.warning("Found out-of-bounds value for chromaticity for filter %s, detector %d." % (self.fgcmPars.lutFilterNames[self.fInd], self.cInd + self.ccdStartIndex))
continue

self.fgcmPars.compCCDChromaticity[self.cInd, self.fInd] = res.x
self.fgcmPars.compCCDChromaticity[self.cInd, self.fInd] = res.x[0]
Copy link

Choose a reason for hiding this comment

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

Do you also need to add the [0] to the if res.x <= -0.99 or res.x >= 0.99: access above?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

No, that's fine. The problem is that numpy doesn't like you setting one value with an array of length 1 anymore. Not sure why, but it doesn't like it. Comparisons to an array of length 1 are fine.

@@ -86,6 +86,37 @@ def getMemoryString(location):

return memoryString


Copy link

Choose a reason for hiding this comment

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

Add a ticket & TODO given the commit message?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It's a tricky synchronization issue... and it won't hurt anything ... but I probably should file a ticket somewhere.

@@ -10,6 +10,8 @@
from .sharedNumpyMemManager import SharedNumpyMemManager as snmm

from .fgcmUtilities import retrievalFlagDict
from .fgcmUtilities import histogram_rev_sorted

Copy link

Choose a reason for hiding this comment

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

Move these above from .sharedNumpyMemManager import SharedNumpyMemManager as snmm like the rest?

np.add.at(expGrayRMSForInitialSelection,
obsExpIndex[goodObs],
EGray[goodObs]**2.)
(EGray[goodObs]).astype(expGrayRMSForInitialSelection.dtype)**2.)

Choose a reason for hiding this comment

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

Should the astype also wrap the **2. here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The opposite, I think. It should be promoted before squaring.

Choose a reason for hiding this comment

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

Ok...you may want to look for other cases (I think I saw others where the promotion was after squaring).

@@ -1221,7 +1221,7 @@ def _chisqWorker(self, goodStarsAndObs):
add_at_1d(partialArray[self.fgcmPars.parRetrievedLnPwvNightlyOffsetLoc:
(self.fgcmPars.parRetrievedLnPwvNightlyOffsetLoc+
self.fgcmPars.nCampaignNights)],
2.0 * deltaMagWeightedGOF[hasRetrievedPwvGOF] * innerTermGOF[hasRetrievedPwvGOF])
(2.0 * deltaMagWeightedGOF[hasRetrievedPwvGOF] * innerTermGOF[hasRetrievedPwvGOF]).astype(np.float64))

Choose a reason for hiding this comment

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

Formatting?

@@ -522,10 +522,10 @@ def _starWorker(self, goodStarsAndObs):

np.add.at(objDeltaAperMeanTemp,
(obsObjIDIndex[goodObs], obsBandIndex[goodObs]),
(obsDeltaAper[goodObs] - self.fgcmPars.compMedDeltaAper[obsExpIndex[goodObs]])/obsMagErr2GO)
((obsDeltaAper[goodObs] - self.fgcmPars.compMedDeltaAper[obsExpIndex[goodObs]])/obsMagErr2GO).astype(objDeltaAperMeanTemp.dtype))

Choose a reason for hiding this comment

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

Formatting?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

🤷‍♂️

Choose a reason for hiding this comment

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

Oh, it may have just looked funny on my screen. Ignore!

np.add.at(expGrayRMSColorSplit[:, c],
obsExpIndex[goodObs[use]],
EGrayGO[use]**2. / EGrayErr2GO[use])
(EGrayGO[use]**2. / EGrayErr2GO[use]).astype(expGrayRMSColorSplit.dtype))
np.add.at(expGrayNGoodStarsColorSplit[:, c],
obsExpIndex[goodObs[use]],
1)

Choose a reason for hiding this comment

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

Is int just implicit here?

np.add.at(superStarOffset,
(self.fgcmPars.expEpochIndex[obsExpIndex[goodObs2]],
self.fgcmPars.expLUTFilterIndex[obsExpIndex[goodObs2]],
obsCCDIndex[goodObs2]),
EGrayGO[mark]/EGrayErr2GO[mark])
(EGrayGO[mark]/EGrayErr2GO[mark]).astype(superStarOffset.dtype))
np.add.at(superStarNGoodStars,
(self.fgcmPars.expEpochIndex[obsExpIndex[goodObs2]],
self.fgcmPars.expLUTFilterIndex[obsExpIndex[goodObs2]],

Choose a reason for hiding this comment

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

Same question about int.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Not a problem here.

@@ -1,6 +1,6 @@
try:
from numba import jit
has_numba = True
has_numba = False
except ImportError:

Choose a reason for hiding this comment

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

Commit message is long. Could do:

Turn off numba usage since it seems to be slower

This is especially evident with new (i.e. version 1.25+) numpy.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Commit is already pushed to fgcm master and released so ...

@@ -1,6 +1,6 @@
try:
from numba import jit
has_numba = True
has_numba = False

Choose a reason for hiding this comment

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

Why try the import at all now?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In case I bring this code back in the future, I guess.

Choose a reason for hiding this comment

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

This doesn't really facilitate that (and I'd argue it's more confusing to leave it like this), but up to you!

@erykoff erykoff merged commit 3be6a4b into lsst-dev Jan 11, 2024
@erykoff erykoff deleted the tickets/DM-42285 branch March 5, 2024 20:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants