MODIS error

[Marston]

Hi,

I ran across a problem with the MODIS code in COSP.F90 (COSP2.0)  lines 576:583 (commit number: 248e01a ):

allocate(modisIN%sunlit(modisIN%Nsunlit),& modisIN%notSunlit(count(cospgridIN%sunlit <= 0)), & modisIN%pres(modisIN%Nsunlit,cospIN%Nlevels+1))
modisIN%sunlit = pack((/ (i, i = 1, Npoints ) /),& mask = cospgridIN%sunlit > 0) modisIN%notSunlit = pack((/ (i, i = 1, Npoints ) /),& mask = .not. cospgridIN%sunlit > 0) modisIN%pres = cospgridIN%phalf(int(modisIN%sunlit(:)),:) The code above allocates a sunlit vector if there are profiles with sun light, if not, this vector modisIN%sunlit is not allocated any memory and remains empty. The last line, modisIN%pres = cospgridIN%phalf(int(modisIN%sunlit(:)),:), will then fail in cases where the entire scene is in darkness, which happens in my case. In cases of complete darkness no modis data is calculated so there needs to be a more sophisticated solution here. Do I simply put an if statement around this whore block to check for any sunlit areas or does anyone have a better solution in mind? Cheers, /M

[dustin...@noaa.gov]

Hi Marston-

Sorry for the delayed response. I promise I wasn't ignoring you, I was on holiday until yesterday.

Thanks for pointing this out. You are correct and these fields should be conditionally allocated. I added some logic to cosp.F90 to avoid this:

       if (modisIN%Nsunlit .gt. 0) then

          allocate(modisIN%sunlit(modisIN%Nsunlit),modisIN%pres(modisIN%Nsunlit,cospIN%Nlevels+1))

          modisIN%sunlit    = pack((/ (i, i = 1, Npoints ) /),mask = cospgridIN%sunlit > 0)

          modisIN%pres      = cospgridIN%phalf(int(modisIN%sunlit(:)),:)

       endif

       if (count(cospgridIN%sunlit <= 0) .gt. 0) then

          allocate(modisIN%notSunlit(count(cospgridIN%sunlit <= 0)))

          modisIN%notSunlit = pack((/ (i, i = 1, Npoints ) /),mask = .not. cospgridIN%sunlit > 0)

       endif

I've updated the gitHub repository with this change.

Cheers,

Dustin

[Marston Johnston]

Hi Dustin,

Hope you had a great vacation. Did you remain in Paris?

I appreciate you looking into this. I admit I was beginning to feel a bit ignored by the group :-)

Nevertheless, what worries me more is that the Intel compiler did not catch this and I got a crash only 

once. I will test MODIS again this week. 

While porting over the changes from the updated COSP.F90, I found the following lines:

       if (associated(cospOUT%calipso_beta_mol))                                         &

            cospOUT%calipso_beta_mol(ij:ik,calipsoIN%Nlevels:1:-1) = calipso_beta_mol

       if (associated(cospOUT%calipso_beta_tot))                                         &

            cospOUT%calipso_beta_tot(ij:ik,:,calipsoIN%Nlevels:1:-1) = calipso_beta_tot

       if (associated(cospOUT%calipso_betaperp_tot))                                     &

            cospOUT%calipso_betaperp_tot(ij:ik,:,:) = calipso_betaperp_tot

What worries me here is the flipping of the vertical structure INSIDE cosp.F90, the above code is only an example. Was this a bug fix?

This is a change from my older version of cosp.F90. Am i missing something here? Why are you flipping the data inside cosp.F90?

Cheers,

/M

Marston S. Johnston, PhD
Department of Earth Sciences
University of Gothenburg, Sweden
Email: marston....@gu.se
SkypeID: marston.johnston
Phone: +46-31-7864901
Only the fruitful thing is true!

--
You received this message because you are subscribed to the Google Groups "COSP users group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cosp-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[dustin...@noaa.gov]

Hi Marston-

My holiday was nice, thanks for asking, but unfortunately not Parisian. It wouldn't of been fair to be in Paris without my wife.

These changes you are referring were meant to be a part of the previous commit (248e01a), but they were left out, so I included them with the commit for the bug you identified. More on this in a moment...

Regarding the flipping of arrays within COSP2. We adopted the convention that vertical inputs/outputs to COSP2, and the simulators, to be ordered top down (TOA-2-SFC). In some cases it wasn't feasible to change all of the internal subroutines to reflect this. So for example, the subroutine cosp_change_vertical_grid used in COSP1 is also used in COSP2 and expects inputs to be ordered from SFC-2-TOA, so we need to flip them in the argument list.

The previous commit (248e01a) was reverting back to this cosp_change_vertical_grid used in COSP1. Originally in COSP2 I used an older version which was not dependent on the vertical ordering, but it turns out this one has some issues which Alejandro pointed out, so we reverted back, but it requires flipping of the vertical dimension. The changes you see in the latest commit are related to this.

Hopefully this helps explain things, but let me know if you have further questions.

Cheers,

Dustin

[yuchien]

Dear all:

I have another question about using MODIS simulator.

As we know, we can get the product ''Ltautmodis'' from MODIS simulator. According to COSP user guid appendix A, we should give ''dtau_s'' (optacal depth of stratiform) and the other variables as the input first.

My question is what's different between input ''dtau_s'' and ouput ''Ltautmodis''?

Does COSP do any pre-process(besides integral value at each level)?

If it do, what kind of pre-process it does?

and the same question for input "tca"(total cloud amount) and output "Lcltmodis"(MODIS total cloud fraction).