[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[McIDAS #JGN-249914]: IMGMAKE

Hi Mike,

re:
> I hate to do this, but I've got another problem I need to bring to
> your attention.
> 
> GOES-16 came back online a short while ago (hurray!),

Yes, BUT IN A TEST MODE!

re:
> and so far I've
> found at least two things that have changed with the Full Disk data.
> The first one is small/simple, but due to some meta-data changes
> goes-restitch.py will now put that data into the /EFD/ directory, as
> opposed to /FullDisk/ as it was prior.

Ryan just uploaded a fix to the GitHub repository for ldm-alchemy that
takes care of this problem.

re:
> I changed the DSSERVE entries
> in that GOESRADDE.BAT file, re-ran it, so McIDAS should see that data
> now.

I suggest grabbing Ryan's modified python script and implementing it
on your system.  You will then have to change your ADDE dataset definitions
back.

re:
> But I've got another problem, agetserv/adirserv appears to be crashing
> when trying to load full disk data now.  Even a command as simple as
> "IMGDISP NPGOESR/FDC02" will result in a failure, and the error output
> I'm pasting below.

OK.  This was not expected, but it is in no way surprising.  Who knows
all of the changes that have been made during the drift.  And, who knows
what changes will be reverted back or new ones implemented before the
18th ?!

re:
> This all obviously just happened literally minutes ago, so I'm still
> going through things on my end to see if anything else has changed.  I
> seem to be having more luck with CONUS data so far, this may just be
> EFD data.  I just wanted to show this to you asap.

Yup.  We were up repointing our GOES-16 dish at 16 UTC.  We have not been
getting data products since the repoint, and this is strongly suggesting
that we need to reboot our GRB 200 receiver. 

re:
> Error output example:
> $ imgdisp.k NPGOESR/FDC02
> *** Error in `agetserv': free(): invalid pointer: 0x00000000016170f0 ***
> ======= Backtrace: =========
> /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fdda7fd07e5]
> /lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fdda7fd937a]
> /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fdda7fdd53c]
> agetserv[0x40f406]
> agetserv[0x40b91f]
> agetserv[0x4047c4]
> agetserv[0x40489e]
> agetserv[0x402933]
> agetserv[0x403400]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fdda7f79830]
> agetserv[0x4026d9]
> ======= Memory map: ========
> 00400000-00428000 r-xp 00000000 fc:06 11288646
> /home/mcidas/bin/agetserv
> 00627000-00628000 r--p 00027000 fc:06 11288646
> /home/mcidas/bin/agetserv
> 00628000-00629000 rw-p 00028000 fc:06 11288646
> /home/mcidas/bin/agetserv
> 00629000-00634000 rw-p 00000000 00:00 0
> 0160c000-0162d000 rw-p 00000000 00:00 0                                  
> [heap]
> 7fdda0000000-7fdda0021000 rw-p 00000000 00:00 0
> 7fdda0021000-7fdda4000000 ---p 00000000 00:00 0
> 7fdda77fb000-7fdda7811000 r-xp 00000000 fc:00 537
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7fdda7811000-7fdda7a10000 ---p 00016000 fc:00 537
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7fdda7a10000-7fdda7a11000 rw-p 00015000 fc:00 537
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7fdda7a11000-7fdda7b19000 r-xp 00000000 fc:00 552
> /lib/x86_64-linux-gnu/libm-2.23.so
> 7fdda7b19000-7fdda7d18000 ---p 00108000 fc:00 552
> /lib/x86_64-linux-gnu/libm-2.23.so
> 7fdda7d18000-7fdda7d19000 r--p 00107000 fc:00 552
> /lib/x86_64-linux-gnu/libm-2.23.so
> 7fdda7d19000-7fdda7d1a000 rw-p 00108000 fc:00 552
> /lib/x86_64-linux-gnu/libm-2.23.so
> 7fdda7d1a000-7fdda7d58000 r-xp 00000000 fc:02 150029
> /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0
> 7fdda7d58000-7fdda7f57000 ---p 0003e000 fc:02 150029
> /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0
> 7fdda7f57000-7fdda7f58000 r--p 0003d000 fc:02 150029
> /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0
> 7fdda7f58000-7fdda7f59000 rw-p 0003e000 fc:02 150029
> /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0
> 7fdda7f59000-7fdda8119000 r-xp 00000000 fc:00 511
> /lib/x86_64-linux-gnu/libc-2.23.so
> 7fdda8119000-7fdda8319000 ---p 001c0000 fc:00 511
> /lib/x86_64-linux-gnu/libc-2.23.so
> 7fdda8319000-7fdda831d000 r--p 001c0000 fc:00 511
> /lib/x86_64-linux-gnu/libc-2.23.so
> 7fdda831d000-7fdda831f000 rw-p 001c4000 fc:00 511
> /lib/x86_64-linux-gnu/libc-2.23.so
> 7fdda831f000-7fdda8323000 rw-p 00000000 00:00 0
> 7fdda8323000-7fdda844c000 r-xp 00000000 fc:02 150297
> /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
> 7fdda844c000-7fdda864b000 ---p 00129000 fc:02 150297
> /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
> 7fdda864b000-7fdda864c000 r--p 00128000 fc:02 150297
> /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
> 7fdda864c000-7fdda864e000 rw-p 00129000 fc:02 150297
> /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
> 7fdda864e000-7fdda8674000 r-xp 00000000 fc:00 487
> /lib/x86_64-linux-gnu/ld-2.23.so
> 7fdda8865000-7fdda8869000 rw-p 00000000 00:00 0
> 7fdda8870000-7fdda8873000 rw-p 00000000 00:00 0
> 7fdda8873000-7fdda8874000 r--p 00025000 fc:00 487
> /lib/x86_64-linux-gnu/ld-2.23.so
> 7fdda8874000-7fdda8875000 rw-p 00026000 fc:00 487
> /lib/x86_64-linux-gnu/ld-2.23.so
> 7fdda8875000-7fdda8876000 rw-p 00000000 00:00 0
> 7ffd8dd5a000-7ffd8dd7b000 rw-p 00000000 00:00 0                          
> [stack]
> 7ffd8ddc8000-7ffd8ddca000 r--p 00000000 00:00 0                          
> [vvar]
> 7ffd8ddca000-7ffd8ddcc000 r-xp 00000000 00:00 0                          
> [vdso]
> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
> [vsyscall]
> imgdisp.k: done

I'll be downloading the new, restitched images for testing in just a bit.

re:
> Here are some of the other basic errors I've come across, still trying
> to track down what commands result in what (lots of scripting so it's
> not entirely clear attm), but sometimes even the same basic command
> above will result in a different error each time:
> Error in `adirserv': corrupted size vs. prev_size: 0x00000000017a12b0
> Error in `agetserv': malloc(): memory corruption: 0x0000000002028f70
> Error in `agetserv': corrupted size vs. prev_size: 0x0000000000c3e500
> Error in `agetserv': free(): invalid pointer: 0x0000000001cff0f0

I have no idea what would cause these errors (meaning that the error
messages are not meaning anything to me at the moment).

re:
> Sorry to show you this on what should otherwise be a Happy GOES-16 Day.

Yup.

re:
> One more thing I've noticed.  When displaying CONUS data, it doesn't
> appear to be getting stretched appropriately anymore.  IR appears
> dimmer as it did before, and visible does not seem like it's getting
> the right square root stretch.  I don't know if this is related to the
> issue I'm having with Full Disk data, but thought you should know this
> too.

OK, another thing to investigate...

First thing for you is to grab the new version of the restitch python
script from GitHub and implement it on your ingest machine.  The next
thing is to revert your ADDE dataset definitions back to what they
were.

Then, stay tuned...

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: JGN-249914
Department: Support McIDAS
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.