1. 19 Jul, 2013 3 commits
  2. 17 Jul, 2013 4 commits
  3. 11 Jul, 2013 6 commits
  4. 10 Jul, 2013 1 commit
  5. 08 Jul, 2013 1 commit
  6. 05 Jul, 2013 4 commits
  7. 04 Jul, 2013 2 commits
  8. 02 Jul, 2013 4 commits
  9. 25 Jun, 2013 2 commits
  10. 24 Jun, 2013 2 commits
  11. 18 Jun, 2013 1 commit
  12. 17 Jun, 2013 1 commit
    • Pierre Cazenave's avatar
      Three main changes: · 38c1d574
      Pierre Cazenave authored
      1. Remove the pevpr data from the list of data to be retrieved (since
         it's not used in the calculations and it is only land-based anyway).
      2. Change the sign of the evaporation data (Et) to match the
         precipitation (FVCOM wants preciptation and evaporation to both have
         the same signs - ocean losing water is negative).
      3. Replace data outside the actual range with NaNs. This might cause
         some things to break later on (e.g. interpolation).
      38c1d574
  13. 06 Jun, 2013 3 commits
  14. 03 Jun, 2013 3 commits
    • Pierre Cazenave's avatar
      Flip the order of the vertical levels in the POLCOMS data to match its depth... · 4032b7ca
      Pierre Cazenave authored
      Flip the order of the vertical levels in the POLCOMS data to match its depth array values (i.e. go from the seabed to the surface instead of the other way around). This changes means the POLCOMS data matches the convention in the FVCOM arrays (where the surface is the first index) and in the POLCOMS depth data. Also change the 1D interpolation to use the pchip interpolation method (shape-preserving piecewise cubic interpolation) instead of linear interpolation. The original change from pchip to linear was because I thought pchip didn't do extrapolation, but since we're scaling the POLCOMS vertical profiles to the FVCOM depths, it doesn't matter. Finally, some miscellaneous changes (moving the creation of the open boundary nodes array to outside the loops and tidying up some of the whitespace/figures code
      4032b7ca
    • Pierre Cazenave's avatar
      Change the way the open boundary nodes are obtained to match that which is in... · a3c594dd
      Pierre Cazenave authored
      Change the way the open boundary nodes are obtained to match that which is in the code which generates Casename_obc.dat. This should stop problems with ordering values in the input arrays where the manner in which the list of open boundary nodes are generated in different ways resulting in different output orders
      a3c594dd
    • Pierre Cazenave's avatar
      Add a couple of diagnostic figures at the end of the function for sanity... · c1e071a9
      Pierre Cazenave authored
      Add a couple of diagnostic figures at the end of the function for sanity checking the function. Also change the way the open boundary nodes are index by using the same approach as is in the code to generate the Casename_obc.dat file. This should avoid problems where the interpolated arrays store the data in a different order from how FVCOM is expecting it (I am assuming here that FVCOM assumes the order of boundary nodes specified in Casename_obc.dat will be common across all input data which use the open boundary nodes. This seems sensible to me)
      c1e071a9
  15. 21 May, 2013 1 commit
    • Pierre Cazenave's avatar
      Add check to avoid setting nodes as river nodes when that node is part of only... · 3ea2af87
      Pierre Cazenave authored
      Add check to avoid setting nodes as river nodes when that node is part of only one element. If this is not added, then the model fills up the element without moving the water out of that element, eventually leading to a crash, which is obviously not ideal. The fix searches for another node in the element which is part of at least two elements, thereby avoiding the "element filling" issue
      3ea2af87
  16. 17 May, 2013 1 commit
  17. 16 May, 2013 1 commit
    • Pierre Cazenave's avatar
      Add support for parallel execution of the vertical sigma layer interpolations.... · bd32806a
      Pierre Cazenave authored
      Add support for parallel execution of the vertical sigma layer interpolations. In addition to this function being launched in parallel, the subfunction grid_vert_interp.m is also parallelised. Although, now that I think about it, that might mean the two functions are competing for the workers in the pool and thus might be suboptimal. I will have to run some tests to see if that is the case
      bd32806a