anupamanand / geotop Goto Github PK

What steps will reproduce the problem?
1. Run the "small_example" test with the TN branch
2. check the output files

What is the expected output? What do you see instead?

8 more files should have been created in ``output_tabs``:

snowice0001.txt
snowice0002.txt
snowliq0001.txt
snowliq0002.txt
snowly0001.txt
snowly0002.txt
snowtemp0001.txt
snowtemp0002.txt

but they are not.

The current documentation says:

    -m GIGABYTES, --memory-per-core GIGABYTES 
        Set the amount of memory
        required per execution core, in gigabytes (Default:
        2). Currently, GIGABYTES can only be an integer number;
        fractional amounts are discarded.

    -w DURATION, --wall-clock-time DURATION
        Set the time limit for each job (default is ‘8’ for ‘8
        hours’). Jobs exceeding this limit will be stopped and
        considered as failed. The duration can be expressed as a whole
        number (indicating the duration in hours) or as a string in
        the form ‘hours:minutes’.

but it is currently wrong, we have to specify the correct syntax,
which comes from the `gc3libs.quantity` module, and it is in the form
"<number> <quantity>" where `<quantity>` is one of:


    'B','GB','GiB','KiB','MB','MiB','PB','PiB','TB','TiB','kB'

for memory and

    'd','day','days','h','hour','hours','hr','hrs','m','microsec','microseconds','min','mins','minute','minutes','ms','nanosec','nanoseconds','ns','s','sec','second','seconds','secs'

for duration.

What steps will reproduce the problem?
1.get the code and compile the tn_exact version 
2.try to run it on any example dir 

here the behaviour of the code:

[cozzini@elcid 1point_example]$ ../../../geotop/geotop .
Error: unable to get the current path: Invalid argument
[cozzini@elcid 1point_example]$ ../../../geotop/geotop 

Error::Run time error
Error::You neet to export the WorkingPath environment variable before to run 
the program
........exiting...
[cozzini@elcid 1point_example]$ export WorkingPath=`pwd`
[cozzini@elcid 1point_example]$ ../../../geotop/geotop 

Error::Run time error
Error::no valid path found on file: 
/u/elab/cozzini/geo2/geotop/test_integration/test_sample_run/1point_example
........exiting...

Check routine:
find_actual_cloudiness_meteodistr() where there are the following missing 
arguments: 
double Lozone, double alpha, double beta, double albedo

Check "phiysical" routines:
find_albedo()
snow_albedo()
shortwave_vegetation()
shortwave_radiation()
longwave_radiation()

What steps will reproduce the problem?
1. compile "matteo" branch
2. run geotop on a directory *different* from the directory containing the 
input files

What is the expected output? What do you see instead?

geotop should run without issues. Instead, it raises an error:

[E] MeteoIO: 
**** backtrace ****
    (1) in mio::FileNotFoundException::FileNotFoundException(std::string const&, std::string const&) from /home/antonio/zurich/usecases/meteoio/lib/libmeteoio.so.2  [0x7f3cb867d9c9]+0x79
    (2) in mio::ARCIO::read2DGrid_internal(mio::Grid2DObject&, std::string const&) from /home/antonio/zurich/usecases/meteoio/lib/libmeteoio.so.2  [0x7f3cb86a02e5]+0x15f5
    (3) in mio::ARCIO::readDEM(mio::DEMObject&) from /home/antonio/zurich/usecases/meteoio/lib/libmeteoio.so.2  [0x7f3cb86a17a9]+0x169
    (4) in mio::IOHandler::readDEM(mio::DEMObject&) from /home/antonio/zurich/usecases/meteoio/lib/libmeteoio.so.2  [0x7f3cb864ec3f]+0x8f
    (5) in mio::BufferedIOHandler::readDEM(mio::DEMObject&) from /home/antonio/zurich/usecases/meteoio/lib/libmeteoio.so.2  [0x7f3cb866a645]+0x175
    (6) at ./geotop/geotop() [0x5370c4]
    (7) at ./geotop/geotop() [0x45482e]
    (8) at ./geotop/geotop() [0x43bf4b]
    (9) in __libc_start_main from /lib/x86_64-linux-gnu/libc.so.6  [0x7f3cb7a05ea5]+0xf5
    (10) at ./geotop/geotop() [0x407799]
[ARCIO.cc:177] FileNotFoundException: ./input_maps/pit.asc


Please use labels and text to provide additional information.

This is probably due to the fact that the current WORKING_DIRECTORY is not 
added to the path of the configuration file in the various values in the Config 
object.

A possible way to fix this is to override configuration options in Config 
object, when they correspond to specific files. However, I don't know what are 
the paths that should be changed, if there is an "official" list or we can just 
check for strings ending in "PATH".

What steps will reproduce the problem?
1. run the test suite (command python ./tests/test_sample_run/test_runner.py) 
on a machine with a recent version of glib (e.g. @2.36.4)

What is the expected output? What do you see instead?

The test which compare the two files fail:
tests/test_sample_run/example/results/output_maps/SWEDENSITYN0001.asc 
tests/test_sample_run/example/output_maps/SWEDENSITYN0001.asc

for instance:
>-9999.000 -9999.000 -9999.000 -9999.000 -nan -9999.000 -9999.000 -9999.000 
-9999.000 -9999.000 -9999.000 -nan -nan
<-9999.000 -9999.000 -9999.000 -9999.000 nan -9999.000 -9999.000 -9999.000 
-9999.000 -9999.000 -9999.000 nan nan

The difference is only due to the new glib which prints whether or not it is a 
nan or a negative nan.

Please use labels and text to provide additional information.

For the purpose of these tests, this difference could be ignored, could you 
relax the test so that nan and -nan are the same thing?

Steps to reproduce the problem:

1. build geotop with meteoio (both branches matteo and tn_exact have the same 
behaviour,  I tried on ubuntu 12.04 LTS and macosx)
2. run tests/test_sample_run/test_runner.py

seems that the following function returns 0.0 instead of 0.7: 
IDWLapseAlgorithm::getQualityRating(const Date& i_date, const 
MeteoData::Parameters& in_param)

I guess this could be due to the lack of data or parameters.

In order to better control the numerical stability of the code, and to have 
better regression tests, we need to produce output files in double precision.

This is not really hard, as geotop already uses double precision floats for all 
the computation. The only changes to do are:

* in ``configure.ac``, to add a configuration option 
(``--enable-double-precision-output`` ?) to control the generation of a define 
``USE_DOUBLE_PRECISION_OUTPUT``
* in all the files that write output files, to use a different format ("%.12g" 
?)

This change should be done on both UZH and TN code, probably using `tn_exact` 
and `uzh_exact` branches.

Current `master` branch has two different functions to compute atmospheric 
transmittance for short wave radiation, `atm_transmittance` and 
`atm_transmittance_iqbal`, defined in radiation.c

Currently, `atm_transmittance` is used, but it would be better to have a 
keyword to define which one must be used.