Can I call fopen () in my process models? Why do I get an abort when I try to use fopen, fprintf, etc.?

Can I call fopen () in my process models? Why do I get an abort when I try to use fopen, fprintf, etc.?

It is fine to use fopen (). However, the operating system can only open a certain number of files at a time, so be sure to close files when you are done with them. If you have too many open files, your system will not allow OPNET software to open the files necessary, causing your simulation to abort. Also, remember that using '' in a string means using it as an escape character to denote characters like newline ( ) tab ( ) etc., therefore, you must use \ to represent '' in a string. There are two good ways to deal with files in process models:1. Declare the FILE* (pointer to FILE datatype) as a state variable.Open the file once in an init state. If using a dynamic process, close the file with fclose() in the termination block. If using a non-dynamic process (root process), then close the file with fclose() in a state triggered by the end of simulation interrupt.OR2. Declare the FILE* as a temporary variable.Open the file each time you need to use it. Close the file with fclose () immediately when you are done. For example, with FILE* output declared as described above:output = fopen (e:\print.out, w);if (output == NULL) { /* print out some error here */ op_prg_odb_print_major (error opening print.out file., OPC_NIL); }else { fprintf (output, %12lf, curTime); }Remember that as part of model development you are doing C programming, and therefore you are subject to all of the common memory access and null-pointer dereferencing issues that C brings with it.Try debugging your code with a source-level debugger (the contributed model xxgdb_op_runsim has an example of using a source-level C debugger to debug OPNET models), or include printf() or other debugging statements in your code. Use op_vuerr to print out the function call stack to determine where in the code the problem occurs. Remember that the function call stack in the error log (/op_admin/err_log) contains information on function names, or process models and state names where errors occur.

DES Kernel->Process Modeling/Coding