I’m trying this option for the first time and came across a little bug: the horizontal grid for the global CCSM CORE files have more points than my little ROMS grid. In nf_fread2d.F, wrk is dimensioned:
real(r8), dimension(2+(Lm(ng)+2)*(Mm(ng)+2)) :: wrk
This isn’t big enough in my case. Why not make it allocatable?
Also, I would dearly love to see the winds handled in the same way as all the other fields. I know it would get tricky if we wanted to say use WRF on it’s rotated grid to drive ROMS on another rotated grid, but CCSM should be simple enough. I’ll look into it.
Yes, I think that this is a good idea but it can be done in regrid.F. Using allocatable arrays is less efficient than automatic arrays. It never occurred to me that this can happen. The wrk scratch array is fine for processing fields of the same size. Alternatively, we can use the Vsize vector in the declaration of wrk. I will have to track Vsize to see if always have values greater than zero for all fields processed.
It is not clear to me what you meant about processing the wind in the same way. The winds need to be RHO-points so we can rotate them correctly to curvilinear grids. Recall that the rotation angle is only defined at RHO-points. Since we need both components in the rotation, having components at U- and V-points data will complicate matters. We will get rotated forcing at the interior only. We always assume that the real word is sampled at RHO-points.
Comment by arango — September 1, 2006 @ 15:46 @ 3:46 pm
After studying all the possible solutions to this problem, I convinced myself that your proposed solution was actually the best. I updated nf_fread2d.F to allocate the scratch vector wrk to the needed length. This vector is deallocated on exit. Thank you for finding this bug.
Comment by arango — September 3, 2006 @ 16:55 @ 4:55 pm