Custom Query (3351 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (52 - 54 of 3351)

Ticket Resolution Summary Owner Reporter
#282 fixed Problem with rotate function willie swr05keh
Description

Hi,

I am running a LAM with a rotated grid on version 6.1 and now 7.1. The rotated pole is at latitude 40, longitude 187.5. I have converted my um files to 32 bit pp files using ff2pp then converted them to little endian using bigend -32 before transferring them to my local machine. I have then used the rotate_sparc function on my local machine to rotate the grid onto a standard lat/lon grid but I have noticed that the rotated latitude and longitudes are wrong - the longitudes are shifted west (see figure). Am I using the rotate function wrong?

Thanks, Kirsty

#283 fixed Output from scatter_field is misaligned willie swr06rjk
Description

I am doing essentially a 'null case', where I gather field A from all (four) processors onto field B on processor 0, and then scatter field B back to all the processors as field C (so A and C should be identical). The gather_field part seems to work fine — fields A (all the parts correctly combined) and B are identical. When I scatter the field back it seems to split it into processors correctly, but the actual segments are mis-aligned. Basically it puts, for processor 0, B(1:8,1:3:5:7) onto C(1:8,1:4) and fills C(1:8,5:8) with zeros. And, for processor 3, B(9:16,9:11:13:15) onto C(1:8,1:4) and fills C(1:8,5:8) with zeros; similarly for processors 1 and 2. So it is ignoring half the input in one direction, but is perfectly aligned in the other direction.

The call is as follows:

CALL GC_SSYNC(NPROC,INFO)

CALL SCATTER_FIELD(AVG_U(:,:,K),GLOB_FLD,

& ROW_LENGTH,ROWS,GLOBAL_ROW_LENGTH,GLOBAL_ROWS, & FLD_TYPE_P,HALO_TYPE_NO_HALO,0,GC_ALL_PROC_GROUP, & ERROR_STATUS,CMESSAGE)

so that field C is AVG_U and field B is GLOB_FLD. The call to gather_field is identical, except with field A instead of C.

The job is xdofh. Thank you for your help!

#286 fixed ERROR: bi_linear_h warning over-writing due to dim_e_out size willie swr01hfd
Description

Hi

I'm trying to run a nested series of UM vn6.1 limited area domains on Hector (job xeakd). I downloaded the umui example job (xcxda) and changed the username etc. This job ran ok. I then changed the input start dump to one I've generated from ECMWF data (xeakb.astart) and this causes the model to crash. The error in the .leave file is a segmetation fault

Segmentation fault! Fault address: (nil)

This is likely to have been caused by either a null pointer dereference or a general protection fault. _pmii_daemon(SIGCHLD): PE 24 exit signal Aborted

I've had a look in the .pe24 file and the error is: bi_linear_h warning over-writing due to dim_e_out size 25760

Any ideas what might be causing the model to crash at the second timestep?

Thanks Helen

Note: See TracQuery for help on using queries.