-
Notifications
You must be signed in to change notification settings - Fork 171
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
MOSAIC association candidate id redundant, includes only single observation #7725
Comments
as an example of the redundancy of c1000 asns, compare the two associations: their input science members, as listed below, are identical
|
Comment by Tony Roman on JIRA: 2739 is a real program. It is a Director's Discretionary program for the purpose of obtaining public outreach images. Information about it is deliberately hidden at the direction of the Director's Office. The program information will be published after all of the press releases associated with this observing program have been completed. |
Hien Tran Tony tells me that each of the mentioned observations are from different targets, so it is ok these are not associated. The question is now, why it got a mosaic candidate ID. We might have to put this on hold until the data is public, however, if this is an issue that cannot wait because it is creating more work for DMS, we need to request for some members of the DMS to be able to see this proposal to further investigate the issue. |
Comment by Jonathan Eisenhamer on JIRA: Hien Tran Standard request: What was the list of candidates passed to the generator to run? |
from the log
|
Comment by Jonathan Eisenhamer on JIRA: Following from Rosa Diaz question: From the association end, it is not clear how a the MOSAIC candidate comes about at all. What in the APT interface creates the MOSAIC candidate? |
Comment by Ernie Morse on JIRA: The mosaic association is used when tiles from a mosaic are split off into new observations. This was first implemented in APT-75132. The ticket quotes this PPS requirement:
The split-off tiles have a new target, centered at the offset of the tile. |
Comment by Jonathan Eisenhamer on JIRA: Thanks! At this moment, MOSAIC candidates are not handled correctly by the association rules, nor can it be handled due to the naming conventions in use. This is because of the differing targets. A higher-level meeting, such as the reformed Association meeting, will be required to determine best course of action. |
Comment by Jesse Doggett on JIRA: I filed a ticket for a similar case, JP-3453 before I saw this one, so I withdrew. It does include copies of the association files generated in case that might be helpful. |
Comment by Howard Bushouse on JIRA: A proposed solution, discussed in an Associations meeting on Jan 22, 2024, would be to eliminate the grouping by target-id for mosaic candidates, because there are some proposals that use different target-ids for different sections/tiles of a single mosaic. Right now the different target-ids are preventing a Lev-3 association that contains all of the mosaic tiles. Removing the constraint on target-id (only for mosaic candidates) would then allow all of the mosaic tiles to be included in a single Lev-3 ASN, as desired. |
Comment by Jonathan Eisenhamer on JIRA: Note: The pure-parallels work has introduced the concept of the target id of "0", or "t0" as it would be in Level 3 naming. The "0" designation in this case is when there is no defined target. It may be possible to use this precedent to resolve the level 3 naming issue. |
Comment by Tyler Pauly on JIRA: PR has been submitted for review - an example output of the new rule is attached, demonstrating the rule type and the members of such an association for the provided pool. |
Comment by Melanie Clarke on JIRA: Fixed by #8798 |
Comment by Tyler Pauly on JIRA: The fix that made it into Build 11.1 generates the expected associations that include all targets of a MOSAIC candidate (across observations), but failed to remove the duplicate associations generated under both o-type and c-type candidates. These duplicates were removed in #8843 , which will be part of Build 11.2. |
Issue JP-3305 was created on JIRA by Hien Tran:
while reprocessing program 2739 it was noted that the l3 associations for the MOSAIC candidate id
{}c1000{
}, which as listed in the pool includes observations 10, 12, 13, each makes up of a single observation only – not all three, as would be expected for a mosaic combination. this makes all thec1000
associations redundant, since all of their products would be covered by the individual -o associations.the targetid is different for each of the observations, likely preventing the full, 3-obs mosaic association from being made. but if such a mosaic is intended, there should be a way to make such a combined product possible.
a summary of
c1000
asns, showing the productnames, number of members, and the observation in each, followsThe text was updated successfully, but these errors were encountered: