X
PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 09 Jan 2008 09:39 AM by  anon
FUNCTION RECOGNITION
 1 Replies
Sort:
You are not authorized to post a reply.
Author Messages

anon



New Member


Posts:
New Member


--
09 Jan 2008 09:39 AM
    We are developing a small rutine that selects and opens an envi file, but during the execution the compiler sends this message: Variable is undefined: FID. Execution halted at: ENVI_GET_DATA The ENVI_GET_DATA instruction is inside a FUNCTION which is not in the main rutine programe. In some others ocassions a different error message apears: unable to allocate memory: to make an array Thanks for your advising !

    Deleted User



    New Member


    Posts:
    New Member


    --
    09 Jan 2008 09:39 AM
    I assume that you are running your code in the IDL Development Environment ("IDLDE"). When code stops by an error in the IDLDE, you have the ability to run commands at the IDL command prompt as if those commands were executing right in the point in the subroutine where IDL halted. Thus if ENVI_GET_DATA is the point where IDL halted, and you have a keyword argument to this procedure like "FID=fid", then you can start to debug by running at the IDL> command prompt the command: IDL> HELP, fid That should probably reveal that 'fid' is "undefined". You then look upwards in your source code from your ENVI_GET_DATA line to see where 'fid' was created or imported. If it was created in the routine that called the subroutine containing ENVI_GET_DATA, then you find the line where it was created, you set your cursor at that line and you select 'Run->Set Breakpoint' at that line. You can type the command: IDL> RETALL to exit from all the routines in your program at one time. Start the program again. Now it should stop at the place where you 'Set Breakpoint'. Now you try to find out what might be wrong with any of the variables that are being used by the command that created (or last manipulated) the 'fid' variable. At some point you will undoubtedly find a bad logic in your program, quite likely at the ENVI_OPEN_FILE call, quite probably with the filepath that is being used. For memory problems you use a similar debugging method. Your code halts at the point where your memory error was issued. The command: IDL> HELP, /MEMORY or, better yet: IDL> print, MEMORY(/CURRENT) will reveal how much of your heap memory is in use. On a 32-bit operating system (most Windows, Mac and Linux) ENVI, ***just when it starts***, will have barely 1 GB of "contiguous memory" for any large data array that you want to import. If you have already imported several large arrays before the memory error is triggered, then ENVI may have just a few hundred megabytes of "unfragmented" contiguous memory bytes available for the next large array. Thus, you compare the output of the above commands to the size of the data that ENVI was trying to import when it triggered the "unable to allocate memory" error. Does it make sense why ENVI truly might have insufficient memory at the point where this error is triggered? James Jones
    You are not authorized to post a reply.