I have 4 test patterns and all written inside a case statement in the testbench. How to call each test at a time through command line during simulation?let me know the command line argument for choosing one testbench case at a time during simulation.
Thank You
I would use a "define" or $test$plusargs and $value$plusargs for that.
You can define the value of a value on the command line using the +define+ argument.
+define+TEST_TO_RUN="4"
In your code you can now grab the value using:
case(`TEST_TO_RUN)
0 : ...
4 : ...
default: // default test or giving error message and stop
endcase
But you have to re-compile the code.
You can also set a value in the code but the command line define always overrides that.
Alternative use $test$plusargs and $value$plusargs.
You can also find information about all of that here
Related
In OpenMDAO V3.1 I am using an ExternalCodeComp to execute a CFD code. Typically, I would call it as such:
mpirun nodet_mpi --design_run
If the above call is made in the appropriate directory, then it will find the appropriate run file and execute the CFD run. I have tried command args for the ExternalCodeComp;
execute = ['mpirun', 'nodet_mpi', '--design_run']
execute = ['mpirun', 'nodet_mpi --design_run']
execute = ['mpirun nodet_mpi --design_run']
I either get an error such as:
RunTimeError: 255, execvp error on file "nodet_mpi --design_run" (No such file or directory)
Or that the command cannot be found.
Is there any way to setup the execute statement to include commandline args for the flow solver when an input file is not defined?
Thanks in advance!
One detail in your question seems incorrect, you state that you have tried execute = "...". The ExternalCodeComp uses an option called command. I will assume that you are using the correct option in your code.
The most correct form to use is the list with all arguments as single entries in the list:
self.options['command'] = ['mpirun', 'nodet_mpi', '--design_run']
Your error msg seems to indicate that the directory that OpenMDAO is running in is not the same as the directory you would like to execute the CFD code from. The absolute simplest solution would be to make sure that you are in the correct directory via cd in the terminal window before executing your python script.
However, there is likely a reason that your python script is in a different place so there are other options I can suggest:
You can use a combination of os.getcwd() and os.chdir() inside the compute method that you have implemented to make sure you switch into and out of the working directory for the CFD code.
If you would like to, you can modify the entries of the list you've assigned to the self.options['command'] option on the fly within your compute method. You would again be relying on some of the methods in the os module for help. os.path.exists can be used to test if the specific input files you need exist or not, and you can modify the command option accordingly.
For option 2, code would look something like this:
def compute(self, inputs, outputs):
if os.path.exists('some_input.file'):
self.options['command'] = ['mpirun', 'nodet_mpi', '--design_run']
else:
self.options['command'] = ['mpirun', 'nodet_mpi', '--design_run', '--other_options']
# the parent compute function actually runs the external code
super().compute(inputs, outputs)
I'm getting this on the console in a QML app:
QFont::setPointSizeF: Point size <= 0 (0.000000), must be greater than 0
The app is not crashing so I can't use the debugger to get a backtrace for the exception. How do I see where the error originates from?
If you know the function the warning occurs in (in this case, QFont::setPointSizeF()), you can put a breakpoint there. Following the stack trace will lead you to the code that calls that function.
If the warning doesn't include the name of the function and you have the source code available, use git grep with part of the warning to get an idea of where it comes from. This approach can be a bit of trial and error, as the code may span more than one line, etc, and so you might have to try different parts of the string.
If the warning doesn't include the name of the function, you don't have the source code available and/or you don't like the previous approach, use the QT_MESSAGE_PATTERN environment variable:
QT_MESSAGE_PATTERN="%{function}: %{message}"
For the full list of variables at your disposal, see the qSetMessagePattern() docs:
%{appname} - QCoreApplication::applicationName()
%{category} - Logging category
%{file} - Path to source file
%{function} - Function
%{line} - Line in source file
%{message} - The actual message
%{pid} - QCoreApplication::applicationPid()
%{threadid} - The system-wide ID of current thread (if it can be obtained)
%{qthreadptr} - A pointer to the current QThread (result of QThread::currentThread())
%{type} - "debug", "warning", "critical" or "fatal"
%{time process} - time of the message, in seconds since the process started (the token "process" is literal)
%{time boot} - the time of the message, in seconds since the system boot if that can be determined (the token "boot" is literal). If the time since boot could not be obtained, the output is indeterminate (see QElapsedTimer::msecsSinceReference()).
%{time [format]} - system time when the message occurred, formatted by passing the format to QDateTime::toString(). If the format is not specified, the format of Qt::ISODate is used.
%{backtrace [depth=N] [separator="..."]} - A backtrace with the number of frames specified by the optional depth parameter (defaults to 5), and separated by the optional separator parameter (defaults to "|"). This expansion is available only on some platforms (currently only platfoms using glibc). Names are only known for exported functions. If you want to see the name of every function in your application, use QMAKE_LFLAGS += -rdynamic. When reading backtraces, take into account that frames might be missing due to inlining or tail call optimization.
On an unrelated note, the %{time [format]} placeholder is quite useful to quickly "profile" code by qDebug()ing before and after it.
I think you can use qInstallMessageHandler (Qt5) or qInstallMsgHandler (Qt4) to specify a callback which will intercept all qDebug() / qInfo() / etc. messages (example code is in the link). Then you can just add a breakpoint in this callback function and get a nice callstack.
Aside from the obvious, searching your code for calls to setPointSize[F], you can try the following depending on your environment (which you didn't disclose):
If you have the debugging symbols of the Qt libs installed and are using a decent debugger, you can set a conditional breakpoint on the first line in QFont::setPointSizeF() with the condition set to pointSize <= 0. Even if conditional breakpoints don't work you should still be able to set one and step through every call until you've found the culprit.
On Linux there's the tool ltrace which displays all calls of a binary into shared libs, and I suppose there's something similar in the M$ VS toolbox. You can grep the output for calls to setPointSize directly, but of course this won't work for calls within the lib itself (which I guess could be the case when it handles the QML internally).
I want to execute a batch file using People code in Application Engine Program. But The program have an issue returning Exec code as a non zero value (Value - 1).
Below is people code snippet below.
Global File &FileLog;
Global string &LogFileName, &Servername, &commandline;
Local string &Footer;
If &Servername = "PSNT" Then
&ScriptName = "D: && D:\psoft\PT854\appserv\prcs\RNBatchFile.bat";
End-If;
&commandline = &ScriptName;
/* Need to commit work or Exec will fail */
CommitWork();
&ExitCode = Exec("cmd.exe /c " | &commandline, %Exec_Synchronous + %FilePath_Absolute);
If &ExitCode <> 0 Then
MessageBox(0, "", 0, 0, ("Batch File Call Failed! Exit code returned by script was " | &ExitCode));
End-If;
Any help how to resolve this issue.
Best bet is to do a trace of the execution.
Thoughts:
Can you log on the the process scheduler you are running this on and execute the script OK?
Is the AE being scheduled or called at run-time?
You should not need to change directory as you are using a fully qualified path to the script.
you should not need to call "cmd /c" as this will create an additional shell for you application to run within, making debuging harder, etc.
Run a trace, and drop us the output. :) HTH
What about changing the working directory to D: inside of the script instead? You are invoking two commands and I'm wondering what the shell is returning to exec. I'm assuming you wrote your script to give the appropriate return code and that isn't the problem.
I couldn't tell from the question text, but are you looking for a negative result, such as -1? I think return codes are usually positive. 0 for success, some other positive number for failure. Negative numbers may be acceptable, but am wondering if Exec doesn't like negative numbers?
Perhaps the PeopleCode ChDir function still works as an alternative to two commands in one line? I haven't tried it for a LONG time.
Another alternative that gives you significant control over the process is to use java.lang.Runtime.exec from PeopleCode: http://jjmpsj.blogspot.com/2010/02/exec-processes-while-controlling-stdin.html.
I've tried to find a table with the definition for each COMPSTAT (related to the tool Control-M workload Automation) return code but without any success.
Can anyone tell me if such a table exists?
Thank you.
It's the return code from whatever task was being executed at that time. By convention, a zero value means 'OK', and anything non-zero means an error of some kind.
Different utilities (i.e. external commands) have different possible return codes, so if the command were SCP then you would look up the code in the SCP documentation, and find that for example, '67' meant 'key exchange failed'.
There is no table that contains the definition of each COMPSTAT return code.
OSCOMPSTAT stand for Control-M Operating System Completion Status.
The value of COMPSTAT is set by the exit code of the command that was called.
Example:
After calling the command [cat file1.txt] the value of COMPSTAT will be:
0 if the file "file1.txt" is found
1 if the file "file1.txt" is not found
After calling the command [ctmfw] the value of COMPSTAT will be:
0 if the specified file is found
7 if the specified file is not found
I'm learning the Flex command-line debugger, and I haven't been able to find information on this particular use case.
I'd like to add a breakpoint to a specific line in one of my class files. I can add breakpoints at the start of a function in a class, but I can't figure out how to set it at a specific line (e.g. line 117 in Foo.as)?
When I try to set one for a file on a given line, I get one at a different location:
(fdb) break Foo 111
Breakpoint 1 at 0x######: file Foo.as, line 115
I've verified the line # I'm specifying is valid, so I don't think the FDB is trying to compensate.
Am I doing something wrong? Is this possible in FDB?
Abso-lutely,
check out the help in fdb, it's fairly helpful :). Just type help or type help then a command. help break gives the output below, lots of nice ways to hook in there, the syntax your using is just missing a colon in between the class and the line number specified, just tried with an MXML file and it worked fine.
Set breakpoint at specified line or function.
Examples:
break 87
Sets a breakpoint at line 87 of the current file.
break myapp.mxml:56
Sets a breakpoint at line 56 of myapp.mxml.
break #3:29
Sets a breakpoint at line 29 of file #3.
break doThis
Sets a breakpoint at function doThis() in the current file.
break myapp.mxml:doThat
Sets a breakpoint at function doThat() in file myapp.mxml.
break #3:doOther
Sets a breakpoint at function doOther() in file #3.
break
Sets a breakpoint at the current execution address in the
current stack frame. This is useful for breaking on return
to a stack frame.
To see file names and numbers, do 'info sources' or 'info files'.
To see function names, do 'info functions'.
Abbreviated file names and function names are accepted if unambiguous.
If line number is specified, break at start of code for that line.
If function is specified, break at start of code for that function.
See 'commands' and 'condition' for further breakpoint control.