확장자가 .cdf 인 파일이네요.
netCDF가 아니고 그냥 CDF 파일일 가능성이 높습니다.

http://www.exelisvis.com/docs/CDF_OPEN.html

CDF와 netCDF는 다른 포맷입니다.

아래의 David Fanning 박사님의 글을 참고하시면 될 것 같습니다.

http://www.idlcoyote.com/tips/exponents.html

다음의 글도 도움이 될 수 있습니다.

http://www.idl-envi.co.kr/callcenter/tips/view.php?num=34&page=4

griddata의 이름이 (irregular를 2차원배열로 만드는 것이어서) 안될 것처럼 보이지만, 2차원 배열을 irregular처럼 사용하고, XOUT, YOUT 키워드를 이용해서 알고자 하는 지점(들)의 X,Y좌표를 명시하면 해당 좌표값만 계산해 냅니다. 예를 들어, 우리나라 전역의 기상예보격자 기온 같은 것이 있다면(동네예보), 이것을 입력자료로 써서, 원하는 위경도(들)의 기온을 유추(내삽)할 수 있다는 것입니다.

도움말을 보시면 확인되는데, Minimum Curvature 알고리즘과 Quintic 알고리즘은 무조건 격자형으로만 리턴을 하고, 나머지 알고리즘(IDW, KRIGING, Nearest Neighbour 등등)은 모두 XOUT, YOUT 키워드를 사용할 수 있습니다.

이 문제는 딱히 답이 있지는 않습니다. 사용하시는 시스템에서 메모리를 할당해 보고 프로그램이 잘 돌아가는지 보시는 게 답이라고 생각합니다.

1. 요즘의 64bit 운영체제에서는 사실상 메모리(RAM)이 많다면 꽤나 큰 배열 할당이 가능합니다. 그런데, 메모리의 크기가 RAM이 감당할 수 있는 크기를 넘어가면 Virtual Memory를 사용하게 되며(HDD의 일부를 RAM 처럼), 속도가 괴로울 정도로 느려집니다. 이건 원하시는 바가 아니라고 생각합니다. 참고로 예전의 32Bit 운영체제라면 2GB 이상의 메모리를 할당하는 것이 불가능했습니다. 아래 다른 이유로 물론 2GB 정도의 메모리를 다 쓰는 배열을 잡기는 불가능했습니다.

2. 배열의 크기는 데이터 타입마다 다른데요, 1byte짜리 byte 형의 10000*10000 즉 bytarr(10000, 10000)이라면, 10000*10000*1 byte의 메모리가 필요합니다. 대략 100MB 정도 되는 크기네요. 이게 Double 형이라면 즉, dblarr(10000, 10000) 이면 10000*10000*8byte가 되므로 800MB 정도가 되는 크기입니다. 그러므로 배열의 요소 개수만 가지고 배열의 크기를 따지는 것은 의미가 없어 보입니다.

3. 배열은 운영체제 안에서, 끊이지 않고 쭉 연결된 메모리 영역을 필요로 합니다. 즉, 아무리 많은 메모리가 있다고 해도, 처음부분에는 운영체제가 차지하고 있고, 중간부분은 어플리케이션들이 차지하고 있고, 마지막 부분은 하드웨어 디바이스 드라이버들이 차지하고 있다면(이보다 더 복잡하겠지만 쉽게 예를 들자면), 처음부터 끝까지 한통으로 쭉 이어진 메모리를 할당할 수가 없게 되고, 결국 우리가 예상하는 것 보다는 작은 크기의 배열만 사용할 수 있게 됩니다. 요즘은 운영체제가 개선되어서 이 부분이 많이 해소되었다고 들었습니다. 즉, 끊어져 존재하는 메모리도 한통으로 묶어 할당할 수 있게 하는 기술인데요, 윈도 계열보다 유닉스/리눅스 계열이 이 부분이 뛰어나다고 합니다. 이런 이유로 IDL 실행 당시의 운영체제 상황이 매번 다르기 때문에, 얼마 크기의 배열을 한통으로 잡을 수 있는지가 정답이 없습니다.

4. 배열을 하나 선언하면 그것으로 원하는 바를 이루는 것은 아닙니다. 이를 이용한 계산도 해야 하고, 이를 다시 다른 변수에 저장도 해야 하고, 배열들 간의 계산도 해야 합니다. 그러므로 어떤 대단한 크기의 배열을 할당했다고 해서 OK가 아닙니다. 상황에 따라 이 배열의 몇 배 되는 공간이 필요할 것입니다. 대부분의 상황이 그렇습니다.

저는 리소스가 넉넉한 리눅스 운영체제에서 Floating 형으로 40000*40000 정도의 배열은 할당해서 사용할 때가 있습니다. 그렇지만 납품용 프로그램을 개발할 때는 이렇게 하지는 않습니다. 이정도의 메모리를 할당할 수 있는 시스템을 보장할 수가 없거든요.

참고로, 매우 큰 영상도 잘 처리하는 ENVI 소프트웨어(IDL로 만들었습니다)는 평범한 4GB RAM 을 가진 시스템에서도 잘 돌아갑니다. 영상을 타일로 쪼개서 처리하도록 개발했기 때문입니다. 물론 “나는 메모리 충분하다”라고 생각하시면 이 타일 크기를 늘릴 수는 있습니다.

이런 이유로, 얼마나 큰 배열을 잡을 수 있나요 에 대한 답은… 사용하시는 시스템에서 필요한 일을 시도해 보시는 것이 답이라고 생각합니다.

기술적 요약
1. 시스템의 물리적 메모리 한계가 존재합니다. HDD를 이용한 Virtual Memory라는 게 존재하지만 이를 가능하면 안쓰는 것이 정신 건강에 좋습니다.
2. 운영체제가 가지는 메모리 한계가 존재합니다. 특히 32bit 운영체제는 하드웨어적 RAM이 얼마가 되든지 2GB 정도의 메모리만 할당이 가능합니다.
3. 조각난 메모리의 효용성 한계가 존재합니다. 여러개의 작은 배열을 잡는데는 문제가 없지만, 큰 배열 하나를 잡는데는 한계가 있습니다.
4. Data Type에 따라 같은 element 수의 배열이라도 메모리상 차지하는 공간의 크기는 많이 차이납니다.
5. 배열 선언이 프로그램의 목적이 아니므로, 계산 과정에서 배열 크기의 여러 배에 해당하는 메모리가 필요해집니다.

Syntax Error는 어디에서 발생하는지 표시가 될 겁니다. 문법에러라서 고치기는 쉬운 편입니다. 어디가 잘못되었다고 나오는지요?

그런데 File 복제라면 FILE_COPY 명령을 쓰시는게 Readfits&Writefits보다 효율적일 거라고 생각합니다.

readcol, dir1+list1, filenames, format=’A’
file_copy, dir0+filenames, dir2

조금 손볼 곳이 있겠지만 전반적으로는 이정도면 될 것 같습니다.

글자가 잘린다는게, 어떤 의미인지 잘 모르겠습니다만, PS의 사이즈가 너무 작아서 그런 것이 아닌가 추측할 뿐입니다.

폰트는 Direct Graphics에서 Postscript를 만들 때 다음 글을 참고하시면 좋을 것 같습니다.
http://www.idlcoyote.com/tips/ps_psfonts.html

꽤 복잡한 코드입니다.
일단, 아래 부분을 IDL이 인식하는 상황인지요?

data=[[data1],[data2],[data3],[data4],[data5],[data6],[data7]]

아래 부분은 IDL이 잘 처리할 것 같긴 한데,
if (month le 9) then month_s=’0’+strtrim(month,2) else month_s=strtrim(month,2)
다음과 같이 처리하는 것이 더 일반적입니다.
month_s=string(month, format='(I02)’)

안녕하세요.

원자료가 최종적으로 원하는 격자크기보다 더 촘촘한 자료라서… 더 간단한 방법으로 처리하는 게 효율적이지 않을까 하는 생각도 있습니다.

일반적으로 무난하게 KRIG2D 함수 같은 것을 사용하시면 어떨까 합니다. 도움말을 찾아 보시면 좋은 예제들이 있습니다. 옵션이 다양하긴 한데, 예제 보시면 사용이 복잡하진 않습니다.

혹시 IDL 8.2 버전대 또는 그 이하 버전을 사용하면, 아래 링크를 한번 검토해 보십시오.

http://blog.daum.net/swrush/228