Custom Query (3351 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (58 - 60 of 3351)

Ticket Resolution Summary Owner Reporter
#2542 duplicate vegetation Leaf Area Index (LAI) for each Plant Functional Type (PFT): December anomaly pmcguire dhertwig
Description

Denise Hertwig and Sue Grimmond reported that the standard veg.func ancillary file for Leaf Area Index (LAI) shows anomalously high values in December in southern England. One might expect the LAI to be high in the summer and low in the winter. The ancillary file shows LAI values that are high in the summer and then going down in the fall, prior to a second large enhancement in LAI in December. They report this for the PRIMAVERA HadGEM3 (coupled) ancillary file.

See the attached files from Denise.

With my suggestion, they have verified this December anomaly over much of Europe by comparing the November LAI with the December LAI with ncview.

The JULES standalone ancillary file for veg.func has header information that says that Heather Ashton (now Rumbold) created the ancillary in 2017. I found her 2009 PhD dissertation/thesis on JULES related topics, wherein in Figs 3.11-3.12 she shows plots of the seasonal variation of the MODIS-derived LAI over southern England and over France. These plots show similar December anomalies to those that Denise and Sue have observed. Her thesis is at: http://www.met.rdg.ac.uk/~bl_met/research/PhDtheses/Ashton_2009.pdf She describes the procedure that she used in 2009 to make LAI for each Plant Functional Type (PFT). This PFT-dependent LAI is derived from the PFT-independent MODIS measurements of LAI by 'green-ness', weighting for each PFT by fixed abundance.

#2543 wontfix vegetation Leaf Area Index (LAI) for each Plant Functional Type (PFT): December anomaly pmcguire dhertwig
Description

Denise Hertwig and Sue Grimmond reported that the standard veg.func ancillary file for Leaf Area Index (LAI) shows anomalously high values in December in southern England. One might expect the LAI to be high in the summer and low in the winter. The ancillary file shows LAI values that are high in the summer and then going down in the fall, prior to a second large enhancement in LAI in December. They report this for the PRIMAVERA HadGEM3 (coupled) ancillary file.

See the attached files from Denise.

With my suggestion, they have verified this December anomaly over much of Europe by comparing the November LAI with the December LAI with ncview.

The JULES standalone ancillary file for veg.func has header information that says that Heather Ashton (now Rumbold) created the ancillary in 2017. I found her 2009 PhD dissertation/thesis on JULES related topics, wherein in Figs 3.11-3.12 she shows plots of the seasonal variation of the MODIS-derived LAI over southern England and over France. These plots show similar December anomalies to those that Denise and Sue have observed. Her thesis is at: http://www.met.rdg.ac.uk/~bl_met/research/PhDtheses/Ashton_2009.pdf She describes the procedure that she used in 2009 to make LAI for each Plant Functional Type (PFT). This PFT-dependent LAI is derived from the PFT-independent MODIS measurements of LAI by 'green-ness', weighting for each PFT by fixed abundance.

#1805 wontfix v8.4 UM-UKCA jobs failing to complete build & compile in 1hour-wallclock on serial queue um_support gmann
Description

Dear NCAS-CMS helpdesk, cc: Sandip

I am encountering a problem this evening where the build-and-compile job for two of my v8.4 UM-UKCA ARCHER jobs I've submitted this evening are not completing within the 1:00:00 wall-clock limit for the serial nodes.

/home/n02/n02/gmann/output/xmhbw000.xmhbw.d16035.t191613.comp.leave

/home/n02/n02/gmann/output/xmhbx000.xmhbx.d16035.t193342.comp.leave

By contrast an equivalent v8.4 UM-UKCA job I submitted this afternoon completed OK in about 20 minutes or so (that's usually now long it takes to compile):

/home/n02/n02/gmann/output/xmhbv000.xmhbv.d16035.t132728.comp.leave

The xmhbv is basically the same job as xmhbx but is just a short 2-day job for testing some code-changes I'd carried out.

That test worked successfully so I proceeded to make those code-changes in the main jobs (xmhbw and xmhbx) but then frustratingly the compile is timing out.

This is doubly frustrating because I have got a 2-job-width ARCHER reservation on at the moment — and the jobs I submitted last night failed overnight with disk quota errors due to the problem Grenville emailed out about with /work filling.

I re-submitted this morning the set of six 5-year 1990s transient Pinatubo-perturbed interactive strat-trop aerosol jobs that had crashed last night. And these are now running OK.

But the 2 jobs I'm submitting this evening are longer 15-year Pre-Industrial Timeslice control jobs for some Krakatoa simulations we'll do.

The plan with this was to run 2 10+-year control jobs in this ARCHER

reservation (Grenville has helped me out getting this all set up).

We got that together last night but it seems to be failing.

Because of the ARCHER reservation, I've elevated the priority for this query to be high — that's because the compile time-out is stopping me submitting these last 2 runs to the 2-job-width reservation.

So I'll lose another overnight run-time period in the reservation.

I'm assuming this is some temporary "system problem" on ARCHER that is causing the build or compilation to go more slowly than it should.

And I'm hoping the "system problem" may just be temporary.

But hopefully the info I've provided above may help make it easier to identify the source of the problem.

Thanks for any help you can give.

Cheers Graham

Note: See TracQuery for help on using queries.