https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/DAMD-140 Data Model <p>We sometimes want to distinguish between pfsDesigns which otherwise might have the same SHA. Two cases are when testing/changing the fibertypes for a given static design, and for distinguishing between designs with sub-arcsec offsets between them.</p> <p>The proposal is to add a optional VARIANT field to the design which would be incorporated to the SHA. If the field does not exist (as for all existing pfsDesigns), the SHA would be unchanged.</p> DAMD-140

Add pfsDesign "variant" field, to be added to the SHA.

Task Normal Done Done cloomis cloomis EngRun Wed, 9 Nov 2022 03:42:57 +0000 Tue, 7 Feb 2023 22:34:43 +0000 Fri, 18 Nov 2022 21:48:10 +0000 0 4 <p>As discussed in commissioning telecon, we also need to add pfsDesignId0 (which is == to pfsDesignId is most cases).<br/> Do we need another ticket, or we stick with this one ?</p> <p>I think we should stick with this one, so update the proposal with an optional <tt>pfsDesignId0</tt> (such that both keywords <tt>pfsDesignId0</tt> and <tt>VARIANT</tt> are present, or not at all) to this ticket.</p> <p>Adding <tt>.variant</tt> from <tt>VARIANT</tt>, and <tt>.designId0</tt> from <tt>PFDSGN0</tt>. Require either both or neither to be set, and and make both 0 if we are not a variant (includes older designs)</p> <p>This is backward-compatible and only adds two PFDU cards, so am not bumping <tt>DAMD_VER</tt>.</p> <p>Note that since the <tt>pfsConfig.write} call requires an already calculated hash, the <b>caller</b> must add add {{variant=N</tt> to the <tt>utils.calculate_pfsDesign</tt> call.</p> <p>All changes look fine. I think we are missing a test for <tt>calculate_pfsDesignId</tt> that could be added.</p> <p>Already merged to master.</p> Blocks INSTRM-1786 Development Rank 0|02qpgz: Reviewers hassan Sprint 2DDRP-2023 A