Hello Ashwin, The changes should be flushed automatically; can you provide a test program which demonstrates the issue? It can be a fairly simple program; once I can observe the issue I should be able to debug it. Thanks, have a great day, -Ward > When I was first trying to install WPS on Ubuntu 12.04 with gfortran and > netcdf-4.3.2 and necdf-fortran-4.4.0 I got this error when running > ./configure after running ./clean -a. > > Your FORTRAN +NETCDF did not run successfully. > > http://mailman.ucar.edu/pipermail/wrf-users/2014/003606.html > > I did not get a response to this message as I thought it to be trivial. But > in light of this geogrid.exe problem maybe it is important to fix this > problem first. As I mentioned in that note both netcdf-4.3.2 and > netcdf-fortran-4.4.0 compiled without any errors. > > > > > > On Wed, Aug 20, 2014 at 11:06 AM, ashwinD12 . <address@hidden> wrote: > > > Hello WRFHelp, > > I believe I have narrowed down the scope of > > the error. What it appears to be doing is that it is copying the value > > of dx to dy since I believe the program believes dy is null. It is > > basically ignoring the values of dy completely. So either this is a > > problem in the syntax of namelist.wps (is it free form or does it > > require a particular syntax such as spaces, commas ? ) > > > > If you can guide me on the source file that writes out the .nc file I > > can put print statements for the dy values and bring this to a > > successful closure. I presume it is in the output_module.f90 file ? I > > note it has a debug module. Question is how to invoke it ? > > Regards, > > Ashwin. > > > > On 8/19/14, WRFHELP <address@hidden> wrote: > > > Ashwin, > > > > > > I cannot repeat your errors here in NCAR. I also don't think it is a > > > problem in netCDF interface. If we change dx and dy in namelist.wps, the > > > results definitely will change accordingly. I am confused by the errors > > > you encounter. > > > > > > On 8/19/14 6:10 AM, ashwinD12 . wrote: > > >> I switched OS to CYGWIN where I have an alternate WRF installation and > > >> tried doing the same thing. The same issue is reproducible over there > > >> as well. The log file is fine but the netcdf output is basically > > >> wrong. I do not know how the module output_module.f90 calls the NETCDF > > >> interface but somewhere the link is broken. This is NOT really a show > > >> stopper as there is a workaround. I need to change DX _AND_ DY to make > > >> sure NETCDF picks up the change but this is a bit of an annoyance as > > >> if I fail to do that then real.exe complains of the difference in > > >> namelist.wps and namelist.input. > > >> > > >> > > >> > > >> Regards, > > >> Ashwin. > > >> > > >> > > >> On Tue, Aug 19, 2014 at 11:13 AM, ashwinD12 . <address@hidden > > >> <mailto:address@hidden>> wrote: > > >> > > >> Hello it goes without a saying that I have run geogrid.exe after > > >> changing namelist.WPS > > >> The geogrid.log file does record the change and maybe the problem > > >> is with the netcdf function call that is writing it out to disk ? > > >> It is caching something ? Or maybe it is an OS fault ? > > >> Is there any way I can debug this further and get back to you ? > > >> > > >> I am on Ubuntu 12.04 with NetCDF 4.3.2 which was compiled with > > >> gfortran 4.8.3. > > >> > > >> > > >> On Tue, Aug 19, 2014 at 5:14 AM, WRFHELP <address@hidden > > >> <mailto:address@hidden>> wrote: > > >> > > >> Please rerun geogrid.exe after you chnage namelist.wps. > > >> > > >> > > >> On 8/16/14 1:48 AM, ashwinD12 . wrote: > > >>> Hello, > > >>> This is my third question for the week. This > > >>> problem is with geogrid.exe and it does not seem to update dy > > >>> when I change the value in namelist.wps. When I type ncdump > > >>> geo_em_d01.nc <http://geo_em_d01.nc> I get the older value of > > >>> dy. I have enclosed my namelist.wps. > > >>> > > >>> Regards, > > >>> Ashwin. > > >> > > >> > > >> > > > > > > > > > > Ticket Details =================== Ticket ID: HRQ-547855 Department: Support netCDF 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.