I am running the "ProSdrOmpsNpEarthController". However, it always complained the size mismatch problem. Do you have any idea how to fix it? Thanks,
The granule ID is: NPP000637124227
Thanks,
/data/data020/weizhong/ADL4.1/CSPP/ADL4.1_Mx6.6/log/ProSdrOmpsNpEarthController_20131203_175736_2709.log:2013/12/03 17:57:41.586.680 (2709.47149403070592): DBG_HIGH /data/data020/weizhong/ADL4.1/CSPP/ADL4.1_Mx6.6/SDR/OMPS/VerifiedRdr/include/ProOmpsVerifiedRdrConvertor.h|1797|Warning: size mismatch in convertVRDR(), size of ccdBuffers_ is 1 but the expected verifiedRdrArrSize is 5
omps NPEarth Sdr: rdr size mismatch?
Re: omps NPEarth Sdr: rdr size mismatch?
The short story:
This is a warning that probably should not even be a warning. It is just informational. It is nothing to worry about.
The long story:
OMPS NP SDR is currently sized to have 1 swath per granule. This sizing is controlled via a LUT. However, the LUT can be configured to place up to 5 swaths per granule. The warning is that the current number of swaths (i.e. 1) is not the maximum number of swaths (i.e. 5). There is nothing wrong with that situation, so that's a misleading message.
OMPS TC SDR has a similar situation. It's currently sized for 5 swaths per granule, but could go up to 15 swaths per granule with some LUT updates. OMPS TC could have a short granule where there are only 4 swaths per granule. This happens periodically based on how swaths line up with granule times.
The OMPS NP and TC IP and EDRs however are not as flexible and are sized at 1 swath for NP and 4-5 swaths for TC.
This is a warning that probably should not even be a warning. It is just informational. It is nothing to worry about.
The long story:
OMPS NP SDR is currently sized to have 1 swath per granule. This sizing is controlled via a LUT. However, the LUT can be configured to place up to 5 swaths per granule. The warning is that the current number of swaths (i.e. 1) is not the maximum number of swaths (i.e. 5). There is nothing wrong with that situation, so that's a misleading message.
OMPS TC SDR has a similar situation. It's currently sized for 5 swaths per granule, but could go up to 15 swaths per granule with some LUT updates. OMPS TC could have a short granule where there are only 4 swaths per granule. This happens periodically based on how swaths line up with granule times.
The OMPS NP and TC IP and EDRs however are not as flexible and are sized at 1 swath for NP and 4-5 swaths for TC.
Kevin Bisanz
Raytheon Company
Raytheon Company
Re: omps NPEarth Sdr: rdr size mismatch?
Hi Kevin,
Thanks for your quick reply. However, the processing is stopped right after this message showed up. I still have trouble to locate where the problem is after the log lever was set to LOW. Here is the log file with lever LOW.
Thanks,
Weizhong
Thanks for your quick reply. However, the processing is stopped right after this message showed up. I still have trouble to locate where the problem is after the log lever was set to LOW. Here is the log file with lever LOW.
Thanks,
Weizhong
- Attachments
-
- ProSdrOmpsNpEarthController_20131204_145259_2234.zip
- (344.85 KiB) Downloaded 754 times
Re: omps NPEarth Sdr: rdr size mismatch?
The log file seems to abruptly stop. Normally at the bottom there are lots of messages about cleaning up things. However the last "normal" message I see near the bottom is "READING INSTRUM PARAMS". This appears to come from $ADL_HOME/OMPS/nadir_profile/src/Get_instrum_params_np.f. Then there are just a few messages about destructors of classes. It appears to me that the algorithm processing seems to have terminated prematurely.
I have a few questions:
--Does this only happen on a single granule or do other granules (both before and after this granule) have the problem also?
--Are there any core files or messages about abnormal termination printed to the terminal?
--Have you tried running this in a debugger, such as gdb? If the process is coring, the debugger may catch it.
--What code baseline are you using? Your first post indicated a directory named Mx6.6. Your recent log file shows some Mx8.0 directories.
--What version of ADL are you using? You can execute "cat $ADL_HOME/.version*".
I have a few questions:
--Does this only happen on a single granule or do other granules (both before and after this granule) have the problem also?
--Are there any core files or messages about abnormal termination printed to the terminal?
--Have you tried running this in a debugger, such as gdb? If the process is coring, the debugger may catch it.
--What code baseline are you using? Your first post indicated a directory named Mx6.6. Your recent log file shows some Mx8.0 directories.
--What version of ADL are you using? You can execute "cat $ADL_HOME/.version*".
Kevin Bisanz
Raytheon Company
Raytheon Company
Re: omps NPEarth Sdr: rdr size mismatch?
We're investigating this a bit more and noticed that the macropixel table (OMPS-NP-MACROTABLE-GND-PI) seems different than expected.
I have a few more questions:
--Is there a reason the macropixel table would be different?
--Have you changed any of the inputs or source code?
I have a few more questions:
--Is there a reason the macropixel table would be different?
--Have you changed any of the inputs or source code?
Kevin Bisanz
Raytheon Company
Raytheon Company
Re: omps NPEarth Sdr: rdr size mismatch?
--Does this only happen on a single granule or do other granules (both before and after this granule) have the problem also?
I ran 17 granules from 09:43 to 09:55 on 10/29/2013. All of them were failed.
--Are there any core files or messages about abnormal termination printed to the terminal?
It showed:
/data/data020/weizhong/CSPP_CM/ADL42_Mx80_snap/home/pub/ClearCase/STAR/JPSS/ADL/ADL/bin/ProSdrOmpsNpEarth.exe
Algorithm Run Failure - ProSdrOmpsNpEarthController, NPP000637118242 Failed During Execution!
Algorithm Run Failure - ProSdrOmpsNpEarthController, NPP000637118242 Failed to Produce an Output Product!
Algorithm Run Failure - ProSdrOmpsNpEarthController, NPP000637118242 Algorithm Stopped Early or Core Dumped!
It seems that it generated a core dumped file. However, I didn't find it yet.
--Have you tried running this in a debugger, such as gdb? If the process is coring, the debugger may catch it.
I will try it and let you know.
--What code baseline are you using? Your first post indicated a directory named Mx6.6. Your recent log file shows some Mx8.0 directories.
I do have all versions of ADL in my machine. I tried Mx6.6 just because ADL didn't run in new Mx8.0 build and I would to test if it is because of the LUT issues.
--What version of ADL are you using? You can execute "cat $ADL_HOME/.version*".
I have ADL4.2+Mx8.0 right now.
[16:26 weizhong@rhw3022 ~]$ cat $ADL_HOME/.version
# The current version of ADL with IDPS algorithms
4.2.1
--Is there a reason the macropixel table would be different?
I don't know. I never changed it. I just use whatever I got from CommonCM.
--Have you changed any of the inputs or source code?
The only file I changed is the Effctivity time in the metadata of OMPS-TC-STRAYLIGHT-LUT from 2013-08-31 to 2014-08-31. However, it should not effect NPEarth, right?
Thanks,
I ran 17 granules from 09:43 to 09:55 on 10/29/2013. All of them were failed.
--Are there any core files or messages about abnormal termination printed to the terminal?
It showed:
/data/data020/weizhong/CSPP_CM/ADL42_Mx80_snap/home/pub/ClearCase/STAR/JPSS/ADL/ADL/bin/ProSdrOmpsNpEarth.exe
Algorithm Run Failure - ProSdrOmpsNpEarthController, NPP000637118242 Failed During Execution!
Algorithm Run Failure - ProSdrOmpsNpEarthController, NPP000637118242 Failed to Produce an Output Product!
Algorithm Run Failure - ProSdrOmpsNpEarthController, NPP000637118242 Algorithm Stopped Early or Core Dumped!
It seems that it generated a core dumped file. However, I didn't find it yet.
--Have you tried running this in a debugger, such as gdb? If the process is coring, the debugger may catch it.
I will try it and let you know.
--What code baseline are you using? Your first post indicated a directory named Mx6.6. Your recent log file shows some Mx8.0 directories.
I do have all versions of ADL in my machine. I tried Mx6.6 just because ADL didn't run in new Mx8.0 build and I would to test if it is because of the LUT issues.
--What version of ADL are you using? You can execute "cat $ADL_HOME/.version*".
I have ADL4.2+Mx8.0 right now.
[16:26 weizhong@rhw3022 ~]$ cat $ADL_HOME/.version
# The current version of ADL with IDPS algorithms
4.2.1
--Is there a reason the macropixel table would be different?
I don't know. I never changed it. I just use whatever I got from CommonCM.
--Have you changed any of the inputs or source code?
The only file I changed is the Effctivity time in the metadata of OMPS-TC-STRAYLIGHT-LUT from 2013-08-31 to 2014-08-31. However, it should not effect NPEarth, right?
Thanks,
Re: omps NPEarth Sdr: rdr size mismatch?
Are you able to repeat my problem?
Here is the GDB result. Do you have any idea how it happened?
Here is the GDB result. Do you have any idea how it happened?
[13:36 weizhong@rhw3022 bin]$ gdb ProSdrOmpsNpEarth.exe
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /data/data020/weizhong/ADL4.1/CSPP/ADL4.2_Mx8.0/bin/ProSdrOmpsNpEarth.exe...done.
(gdb) run /data/data020/weizhong/ADL4.1/CSPP/ADL4.2_Mx8.0/log/ProSdrOmpsNpEarthController_NPP000637124227.xml
Starting program: /data/data020/weizhong/ADL4.1/CSPP/ADL4.2_Mx8.0/bin/ProSdrOmpsNpEarth.exe /data/data020/weizhong/ADL4.1/CSPP/ADL4.2_Mx8.0/log/ProSdrOmpsNpEarthController_NPP000637124227.xml
[Thread debugging using libthread_db enabled]
[New Thread 0x2aaab5c9e700 (LWP 31374)]
[New Thread 0x2aaab5e9f700 (LWP 31375)]
At line 297 of file Get_instrum_params_np.f
Fortran runtime error: Array reference out of bounds for array 'waves', upper bound of dimension 2 exceeded (151 > 150)
[Thread 0x2aaab5c9e700 (LWP 31374) exited]
[Thread 0x2aaab5e9f700 (LWP 31375) exited]
Program exited with code 02.
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6.x86_64 libgcc-4.4.7-4.el6.x86_64 libgfortran-4.4.7-4.el6.x86_64 libgomp-4.4.7-4.el6.x86_64 libstdc++-4.4.7-4.el6.x86_64
Re: omps NPEarth Sdr: rdr size mismatch?
Sorry for the delayed response on this. I was on PTO on Friday and had to leave early today.
I believe that we've figured out the issue. Our OMPS expert noticed that the CCR in the file name of the macro pixel table name listed CCR 0625. For example, line 28132 of your log file. While that CCR was delivered to Raytheon, apparently there was some issue with it and we were told not to use it. However, it was checked into our CM system.
Because we were told not to use it, the CCR 0625 table was never put into the operational system.
Unfortunately it did find its way into the ADL data packages, as you discovered. This happened because the script which creates those data packages made the assumption that every file available under a directory was a valid candidate for inclusion in the data package. It then picked the latest file. While the assumption that every file is a valid candidate was probably valid when the script was created a while back, it is not valid now (since CCR 0625 was added to the directory).
As for how to fix your issue, you need to remove the 0625 tables (there are several OMPS NP and TC tables) and replace them with something else. I am not sure if a valid replacement is currently available on Common CM. I will need to check with someone who has access to Common CM (Most Raytheon people don't have access due to restrictions).
I will try to figure out the correct tables and post back.
I believe that we've figured out the issue. Our OMPS expert noticed that the CCR in the file name of the macro pixel table name listed CCR 0625. For example, line 28132 of your log file. While that CCR was delivered to Raytheon, apparently there was some issue with it and we were told not to use it. However, it was checked into our CM system.
Because we were told not to use it, the CCR 0625 table was never put into the operational system.
Unfortunately it did find its way into the ADL data packages, as you discovered. This happened because the script which creates those data packages made the assumption that every file available under a directory was a valid candidate for inclusion in the data package. It then picked the latest file. While the assumption that every file is a valid candidate was probably valid when the script was created a while back, it is not valid now (since CCR 0625 was added to the directory).
As for how to fix your issue, you need to remove the 0625 tables (there are several OMPS NP and TC tables) and replace them with something else. I am not sure if a valid replacement is currently available on Common CM. I will need to check with someone who has access to Common CM (Most Raytheon people don't have access due to restrictions).
I will try to figure out the correct tables and post back.
Kevin Bisanz
Raytheon Company
Raytheon Company
Re: omps NPEarth Sdr: rdr size mismatch?
We believe the issue is sorted out and new data packages for OMPS have been created. They should be posted to Common CM at some point soon.
The updated files should not have any files from CCR 625.
Please post back if you have questions or further issues.
The updated files should not have any files from CCR 625.
Please post back if you have questions or further issues.
Kevin Bisanz
Raytheon Company
Raytheon Company
Re: omps NPEarth Sdr: rdr size mismatch?
The new LUT for OMPS works. The only problem is the Effectivity time in "OMPS-TC-STRAYLIGHT-LUT". It is too short. It is only from 2013-06-24 to 2013-08-31. In order to run the recent data, I have to change it. However, I am not sure if it will effect the final result? Do you know where I can find the updated LUT?
Thanks.
Thanks.