Help with VIIRS aerosol source code compiling at ADL4.1

[jhuangadl]

Dear all,

Any chance anyone can kindly help us to test compiling the attached VIIRS aerosol source code?

We are pretty sure it can be compiled because it is from the IDPS version of the code. But somehow our ADL4.1 refuse to compile it successfully for us. It listed an error and I couldn't locate the problem. I wish to find out whether it is my system problem or it is an ADL problem. Any kind help is deeply and sincerely appreciated.

The compiling I did was:
at $ADL_HOME/EDR/VIIRS/aerosol/src
run:

Code: Select all

make clean library program

The final line of the screen display was;

Code: Select all

make: *** [ProEdrViirsAerosol.o] Error 1

The screen display was too long and I couldn't find where (which line) the error occurred, although I found many many warning messages. I trid to output the screen display to a file, but unsuccessful.

Any help is sincerely appreciated!

Thank you,
Jingfeng

P.S. please change the file extension of the attached txt file to cpp for compiling. Thanks!

[bhenders]

Jingfeng,

I'll try to install the file here shortly on a development box here and compile it. Any chance you could pipe the build output to a file and then paste in the error that you are getting. I could probably tell more from actually seeing the error you are getting.

If you could upload the complete build output that might be helpful also. You could also edit the Imakefile to turn off or remove the -Wall flag which turns on all warnings so that you can see your error more easily.

Thanks,

Bryan Henderson
Raytheon Company

[bhenders]

Jingfeng,

I tried to compile the file for ADL 4.1. The file is technically not synched with ADL 4.1 release, it looks to be without having the ADL 4.1 updates that were made. The compile error I get is a conflict with the CURRENT_GRANULE constant. It is the following line in the file. I merely commented out the line to make it compile successfully. You might want to just get the latest ADL 4.1 source/data tar release that is synced with the Mx6 build that has the changes you want. You're probably ok just commenting out the line but there are no guarantees.

WAS:
// Indicates the tasked granule
const Int32 CURRENT_GRANULE = 0;

CHANGE TO:
// Indicates the tasked granule
// const Int32 CURRENT_GRANULE = 0;

[jhuangadl]

Many thanks, Bryan,

I will really love to know more about this -Wall flag thing so that I don't have to bother you guys next time when I was trying to locate the error.
But I did not find it at a significant place in the Imakefile. Am I overlooking anything? Thanks!

Code: Select all

#include "PRO_rules"
#ifdef XL
#ifndef Debug
OPTIMIZE_OPT=-O5 -qarch=pwr4 -qtune=pwr5 -qcache=auto -qstrict
#endif
#endif

AER_H = $(ADL_HOME)/EDR/VIIRS/aerosol/include/AutoGeneratedProEdrViirsAerosol.h
AER_CPP = $(ADL_HOME)/EDR/VIIRS/aerosol/src/AutoGeneratedProEdrViirsAerosol.cpp

TARGET_A=$(LIBDIR)/libProEdrViirsAerosol.a
TARGET_SO=$(LIBDIR)/libProEdrViirsAerosol.so
TARGET_EXE=
TARGETS=$(TARGET_A) $(TARGET_SO)

# my auto-generated source files
GEN_CPP_SRCS = $(AER_H) $(AER_CPP)

#if DIAGNOSTIC_ENABLED
DIAGNOSTIC_HEADERS=-I../include/Diagnostics
DIAGNOSTIC_C_SRCS=Diagnostics/ProEdrViirsAerosolDiagnostics.cpp
DIAGNOSTIC_F_SRCS=
#else
DIAGNOSTIC_HEADERS=
DIAGNOSTIC_C_SRCS=
DIAGNOSTIC_F_SRCS=
#endif

HEADERS =  -I../include \
           -I${ADL_HOME}/CMN/Utilities/INF/include \
           -I${ADL_HOME}/CMN/Utilities/INF/common/exceptions/include \
           -I${ADL_HOME}/CMN/Utilities/INF/util/time/include \
           -I${ADL_HOME}/Geolocation/CmnGeo/include \
           -I${ADL_HOME}/Geolocation/novas-c201/include	\
	   $(DIAGNOSTIC_HEADERS)

#ifdef XL
SYSLIB = -L${ADL_HOME}/lib \
	 -lProEdrViirsAerosol \
	 -lmass \
         -lessl
USER_CCFLAGS = -qstrict
#else
SYSLIB = -L${ADL_HOME}/lib \
	 -lProEdrViirsAerosol
#endif



C_MAIN_SRC = ProEdrViirsAerosolMain.cpp
C_LIB_SRCS = ProEdrViirsAerosol.cpp \
	     ProEdrViirsAerosolDelegate.cpp \
             AutoGeneratedProEdrViirsAerosol.cpp \
             $(DIAGNOSTIC_C_SRCS)

LIB_OBJS = ${C_LIB_SRCS:.cpp=.o}
MAIN_OBJ = ${C_MAIN_SRC:.cpp=.o}

ProBuildLibraryAndAutoGenExecutable($(GEN_CPP_SRCS),$(TARGET_A),$(TARGET_SO),$(TARGET_EXE),$(LIB_OBJS),$(MAIN_OBJ),$(SYSLIB),$(SRC_GEN_DEP_LIBS),ProEdrViirsAerosol,48,VIIRS,EDR)
ProDepends($(HEADERS), $(C_LIB_SRCS) )
ProCleanAutoGen($(GEN_CPP_SRCS) $(C_MAIN_SRC))

Jingfeng,

I'll try to install the file here shortly on a development box here and compile it. Any chance you could pipe the build output to a file and then paste in the error that you are getting. I could probably tell more from actually seeing the error you are getting.

If you could upload the complete build output that might be helpful also. You could also edit the Imakefile to turn off or remove the -Wall flag which turns on all warnings so that you can see your error more easily.

Thanks,

Bryan Henderson
Raytheon Company

[jhuangadl]

Many thanks, Bryan,
I commented the line out and compiled the file successfully. I will try to get the latest tar release and give another try. But this version is already an IDPS version -- does this mean there are difference between ADL tar release and IDPS operational version?
Thanks!
Jingfeng

Jingfeng,

I tried to compile the file for ADL 4.1. The file is technically not synched with ADL 4.1 release, it looks to be without having the ADL 4.1 updates that were made. The compile error I get is a conflict with the CURRENT_GRANULE constant. It is the following line in the file. I merely commented out the line to make it compile successfully. You might want to just get the latest ADL 4.1 source/data tar release that is synced with the Mx6 build that has the changes you want. You're probably ok just commenting out the line but there are no guarantees.

WAS:
// Indicates the tasked granule
const Int32 CURRENT_GRANULE = 0;

CHANGE TO:
// Indicates the tasked granule
// const Int32 CURRENT_GRANULE = 0;

[jhuangadl]

Thanks, Bryan,
Here is the good news. I used the latest IDPS package release and the aerosol code there can be compiled successfully. Interesting. I learned more from you.
Have a nice day!
Thanks,
Jingfeng

[bhenders]

Jingfeng,

Glad to hear you got past your prolbem and the latest code was successful for you. FYI the -Wall flag turns on all compiler warnings for the GCC compilers. ADL has this option on by default. You can turn it off if you desire by updating $ADL_HOME/imakeconf/PRO_Config. Just search for -Wall and delete it. Though the danger of removing it is that compiler warnings are often useful in denoting coding errors or issues, especially if you are writing new code and by turning it off you will no longer see them.

I'm still hopeful that we will eventually clean up all of the ADL compiler warnings as part of the current IDPS development that is going on but the problem is that warnings are often low priority.

Bryan Henderson
Raytheon Company

[jhuangadl]

Thank you, Bryan,
I am glad that I am learning more and more from you on the ADL.
I think I removed all the -Wall in the PRO_Config file, however, when I run

Code: Select all

make clean library program

at

Code: Select all

$ADL_HOME/EDR/VIIRS/aerosol/src/

I still get lots of warning messages on my screen. Does this mean there are more files I have to tweak with?
Thanks!
Jingfeng

[houchin]

With ADL as it stands today, warnings are a fact of life. If you are just compiling the officially distributed version or making only a minor change, you should just learn to ignore them.

However, if you are making extensive changes or starting a long development task, you may want to consider fixing the warnings yourself. This is exactly what I did for the Aerospace RSBAutoCal effort. If you examine the warnings, you'll quickly notice that while it looks like lots and lots of issues, most of the warnings are for the same line of code being presented to you over and over, as many of the problem files end up being included for almost every single source file. It was a few months ago, but I believe it took only about an hour to make the modifications to ADL 4.0 with Mx6.2 updates that were required to allow RSBAutoCal to compile with zero warnings. I've attached the differences as output by subversion on our code repository detailing the changes. Note that these fixes only covered the warnings that came up when compiling our new algorithm code; compiling other parts of code will still generate additional warnings. I would think that if you're focusing on a different algorithm, you could probably fix the warnings in about the same amount of time.

The changes I made fell into only a few categories:

• "typedef" being deprecated for struct and enum definition
• Signed/unsigned mismatch
• Inconistent constness in the log classes (this ended up being required because of specific logging extensions we put into RSBAutoCal
• Unused variables defined in header files. For this one, I made the assumption that they were used somewhere in ADL, but just not in RSBAutoCal, so I couldn't really fix it without likely moving code between header and source files, which I didn't want to do. Instead, I defined __IN_RSBAUTOCAL__ in our makefile and then wrapped the problem elements inside #ifndef directives.
• There's also one major fix in here that Bryan provided to deal with issues we had with the SDR code generator. I believe that update got into either 4.1 or 4.2. It's in CMN/SrcAutogen/src/AdlCmnGenerateDerivedAlgMain.cpp

Bryan seemed to indicate these fixes really were coming, and I hope that means sooner rather than later. If you're making code modifications, it is incredibly difficult to find your real error messages and the warnings you need to pay attention to in the compiler output with -Wall (and I did not want to turn off -Wall).

[bhenders]

Jingfeng,

If you want to turn them all off, the correct replacement in PRO_config is to change the -Wall to -w (just removing -Wall still produces some warning output like typedef warnings, etc). The step that you are missing below I believe to reduce the number of warnings is to do the make imake step to actually expand the Imakefile to a Makefile with the -Wall flag replaced.

I agree with what Scott said in a response, that if you are writing new code it is probably prudent that you leave it on and clean up the warnings for the module that you are interested in.

You could use the PRO_Config override for the rest of the ADL framework and algorithms and then manually put the -Wall flag in to the appropriate algorithm software that you have the most interest in.

In the end, warnings are a good thing, it just too bad that we never found enough time/funding to get them all cleaned up in IDPS/ADL.

Thanks,

Bryan Henderson
Raytheon Company