HiRISE not recognized as usgscsm camera model in GXP

[thareUSGS]

In building test examples for our library I am having an odd issue with the test HiRISE stereo models for GXP. The model is not getting initialed, so in the interface, I get "Math Model: Identity". When testing with the sample CTX (link below), I correctly get "Math Model: USGS_ASTRO_LINE_SCANNER_SENSOR_MODEL" in a multiport view.

For GXP, download the *_cub.zip files for testing HiRISE, either model (includes HiRISE cubes and ISD json files): https://github.com/USGS-Astrogeology/usgscsm/wiki/CSM-Stereo-Testing-Examples

locally they are here: /archive/projects/SOCET_GXP/test_models_GXP/HiRISE/

• I am currently testing in GXP 4.4.1 (cloud), but will test ASAP in GXP 4.4.0 (at work) tomorrow.
• These were created using the ALE v 0.8.5 ; py39h1a9c180_1 ; conda-forge
• HiRISE were processed a while ago - IsisVersion = "3.6.0 | 10-26-2018" (typical manner as processed for SocetSET)
• I am using usgscsm build 0.1.376, https://ci.appveyor.com/project/jlaura/usgscsm/builds/37637004

I have exported a usgscsm log and attach here also. For getting a log to work in the cloud machine you can edit this file: C:\Program Files\BAE SYSTEMS\SOCET GXP 4.4.1\Exe\SocetGxp.env and add the line: USGSCSM_LOG_FILE=C:\usgscsm.log

usgscsm.log

[jlaura]

Is GXP constructing the SAR model?

[2021-02-10 16:37:04.404] [usgscsm_logger] [info] Constructing UsgsAstroSarSensorModel
[2021-02-10 16:37:04.404] [usgscsm_logger] [info] Resetting UsgsAstroSarSensorModel
[2021-02-10 16:37:04.404] [usgscsm_logger] [info] UsgsAstroSarSensorModel constructing state from ISD, with ...

[jessemapel]

GXP is just blinding trying the different models. It should gracefully fail when it checks if it can construct the SAR and it does. What's happening is that the LS or Framer construction code is seg faulting somewhere. Hence the log is truncated.

[thareUSGS]

Could it be a simple as a string size limit somewhere on load? I noticed the log was truncated too.

[jessemapel]

No it's not strings, I've got it narrowed down to somewhere in the calculation of the sensor to target rotations.

[jessemapel]

Okay, these HiRISE images are little unique in that they have polynomial based dejittered pointing, but no Angular Velocity information available. This is causing a problem in ALE when we try to chain some of the rotations together to get the sensor to target rotation. So, I'm going to put a PR in over in ALE and then once that's merged, I'll tick the embedded ALE over here. That should allow you to re-test this in GXP with the new artifacts. You won't need to update the ISDs, they are still perfectly valid.