We are trying to test the co-simulation options of Dymola and created a fmu-file. We installed/built the FMILibrary-2.0b2 and FMUChecker-2.0b1 from www.fmi-standard.org.
I encountered an issue while trying to run the FMUChecker (fmuCheck.linux32) of a fmu-file my colleague created with Dymola. Wenn i create with my Dymola-license an fmu-file from the same Dymola model this issue is not reproducible. Because fmuCheck.linux32 runs fine without any error messages.
My colleague can run both files without problems!
As it is our goal to use this option for co-simulation i tried to run the fmu file on a pc without Dymola and again i got the same error with both my fmu-copy and the one my colleague created.
Here's the Error Message
fmuCheck.linux32 PemFcSysLib_Projects_Modl_SimCoolCirc.fmu
[INFO][FMUCHK] Will process FMU PemFcSysLib_Projects_Modl_SimCoolCirc.fmu
[INFO][FMILIB] XML specifies FMI standard version 1.0
[INFO][FMI1XML] Processing implementation element (co-simulation FMU detected)
[INFO][FMUCHK] Model name: PemFcSysLib.Projects.Modl.SimCoolCirc
[INFO][FMUCHK] Model identifier: PemFcSysLib_Projects_Modl_SimCoolCirc
[INFO][FMUCHK] Model GUID: {6eba096a-a778-4cf1-a7c2-3bd6121a1a52}
[INFO][FMUCHK] Model version:
[INFO][FMUCHK] FMU kind: CoSimulation_StandAlone
[INFO][FMUCHK] The FMU contains:
18 constants
1762 parameters
26 discrete variables
281 continuous variables
0 inputs
0 outputs
2087 internal variables
0 variables with causality 'none'
2053 real variables
0 integer variables
0 enumeration variables
34 boolean variables
0 string variables
[INFO][FMUCHK] Printing output file header
time
[INFO][FMILIB] Loading 'linux32' binary with 'standard32' platform types
[INFO][FMUCHK] Version returned from FMU: 1.0
[FMU][FMU status:OK]
...
[FMU][FMU status:OK]
[FMU][FMU status:Error] fmiInitialize: dsblock_ failed, QiErr = 1
[FMU][FMU status:Error] Unless otherwise indicated by error messages, possible errors are (non-exhaustive):
1. The license file was not found. Use the environment variable "DYMOLA_RUNTIME_LICENSE" t
[FATAL][FMUCHK] Failed to initialize FMU for simulation (FMU status: Error)
[FATAL][FMUCHK] Simulation loop terminated at time 0 since FMU returned status: Error
FMU check summary:
FMU reported:
2 warning(s) and error(s)
Checker reported:
0 Warning(s)
0 Error(s)
Fatal error occured during processing
I think a fmu-file shouldn't need a Dymola license to be simulated, therefore i can't see the reason this simulation failed.
What could be the reason for this strange behaviour?
Partially this is the same Error Message of this Issue
Initialization of a Dymola FMU in Simulink
Any suggestions are much appreciated. Thank you.
It seems that dymola has not set the path variable to the license-file in ubuntu. We have done this manually by adding the following lines to .bashrc
# Dymola runtime license, path
DYMOLA_RUNTIME_LICENSE=$HOME/.dynasim/dymola.lic
export DYMOLA_RUNTIME_LICENSE
now we can simulate each others fmu-files!
Whether an exported FMU requires a license depends on whether the copy of Dymola that exported the FMU had the "Binary Export" feature. The bottom line is that if you want unencumbered FMUs from Dymola, you have to pay for an extra licensed feature.
Related
I'm using abc01008.exe to synthesize combinational functions.
I have been using mcnc.genlib and stdcell.lib with no problems.
I would like to use a different std_cell libray that is in the liberty format.
When I type 'rty' or 'read_liberty' I do get the following error:
abc 01> rty
** cmd error: unknown command 'read_liberty'
(this is likely caused by using an alias defined in "abc.rc"
without having this file in the current or parent directory)
abc 01> read_liberty
** cmd error: unknown command 'read_liberty'
(this is likely caused by using an alias defined in "abc.rc"
without having this file in the current or parent directory)
Can someone point me in the right direction?
Thx in advance
I had the following situation: I'm in a live user mode debugging session and I wanted to show the win32k!_W32Process structure. Unfortunately, win32k is a kernel mode SYS file, so the symbols are not available in the user mode session.
I know that I can always load a DLL, EXE or SYS as a dump file and then inspect the symbols. Usually I would do that via File/Open Crash Dump.
This time, I wanted to show the participants of a debugging workshop that it's possible to debug multiple systems at the same time, so I opened the Win32K.sys via WinDbg's command prompt:
0:003> |
. 0 id: 10fc attach name: [...]\NetHeaps.exe
0:003> .opendump C:\Windows\winsxs\[...]\win32k.sys
Loading Dump File [C:\Windows\winsxs\[...]\win32k.sys]
Opened 'C:\Windows\winsxs\[...]\win32k.sys'
||0:0:003>
As we can now see, we have 2 systems and I'm currently on the live debugging system:
||0:0:003> ||
. 0 Live user mode: <Local>
1 Image file: C:\Windows\winsxs\[...]\win32k.sys
I thought I could switch to the other system now, but that does not work:
||0:0:003> ||1s
^ Illegal debuggee error in '||1s'
I would not have worried too much, but it can't find the symbols of win32k in this case:
||0:0:003> .reload
Reloading current modules
...........................
||0:0:003> dt win32k!_W32Process
Symbol win32k!_W32Process not found.
The problem is not in the || command, it's in the .opendump command.
The help says:
After you use the .opendump command, you must use the g (Go) command to finish loading the dump file.
Be aware that this will also run your live process. Therefore, freeze the threads first (~*f) and unfreeze later (~*u).
After that you can switch the system and display the type:
||1:1:004> ||
0 Live user mode: <Local>
. 1 Image file: C:\Windows\winsxs\[...]\win32k.sys
||1:1:004> dt _W32Process
win32k!_W32PROCESS
+0x000 Process : Ptr64 _EPROCESS
+0x008 RefCount : Uint4B
+0x00c W32PF_Flags : Uint4B
[...]
I have this program that listens to the microphone and tries to recognize what was said:
#!/usr/bin/env python3
import speech_recognition
recognizer = speech_recognition.Recognizer()
class Recognition:
def __init__(self):
self.recognizer = speech_recognition.Recognizer()
def listen(self):
with speech_recognition.Microphone() as source:
self.recognizer.adjust_for_ambient_noise(source)
self.audio = self.recognizer.listen(source)
def recognize_sphinx(self):
decoder = self.recognizer.recognize_sphinx(self.audio, show_all=True)
for best, i in zip(decoder.nbest(), range(10)):
return best.hypstr
r = Recognition()
r.listen()
print(r.recognize_sphinx())
Although the code works, it does display the following warnings along with the output:
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
potato
The problem is I want a script to execute the code above and read its output (potato), but the returned result is mixed with all those errors. I tried the solution I saw here, but it only suppress the alsa warnings. Probably messing with alsa/pulseaudio configs will solve this problem, but I don't want to do that on every machine that runs the code.
I also tried redirecting stdin/stderr to null, but didn't suppress anything.
I have a workaround in mind that is, when the script runs this program, to get only the last line, but I want that only as a last resource.
The warning/status messages go to the standard error output (stderr), while the output of your print() call goes to the standard output (stdout).
It should be trivial to separate the two.
If you want to actually suppress the warning/status messages, you can have a look at my answer to the SO-question you were mentioning, or the more verbose answer I've linked to from there.
Folks, I am stumbling upon quite a weird issue. I am running a job with mpirun command:
mpirun -np 4 ~/opt/stuff/OSMC
Sometimes (the execution depends on a number of random values) one of the four processes dies:
Image PC Routine Line Source
OSMC 000000000050B54D Unknown Unknown Unknown
OSMC 000000000050A055 Unknown Unknown Unknown
OSMC 00000000004BA320 Unknown Unknown Unknown
OSMC 000000000047976F Unknown Unknown Unknown
OSMC 0000000000479B72 Unknown Unknown Unknown
OSMC 000000000043B7DC mpi_m_mp_exchange 306 mpi_m.f90
OSMC 0000000000430880 mpi_m_mp_coagulat 85 mpi_m.f90
OSMC 000000000041304B op_m_mp_op_run_ 81 op_m.f90
OSMC 000000000040FF22 osmc_m_mp_run_ 543 OSMC_m.f90
OSMC 000000000040FD09 MAIN__ 28 OSMC_m.f90
OSMC 000000000040FC4C Unknown Unknown Unknown
libc.so.6 000000362081ED5D Unknown Unknown Unknown
OSMC 000000000040FB49 Unknown Unknown Unknown
--------------------------------------------------------------------------
mpirun has exited due to process rank 1 with PID 28468 on
node rcfen04 exiting without calling "finalize". This may
have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
--------------------------------------------------------------------------
The system prints no core dump, so I have no more informations apart of this short summary. I gave a look in mpi_m.f90 line 306, where an existing array is set to 0.
The system should be able to print a core dump file, since:
[user#host path]$ ulimit -a
core file size (blocks, -c) unlimited
...
This is the piece of code that is reported in the short summary:
module mpi_m
implicit none
...
real(wp),allocatable :: part(:,:) ! ARRAY DECLARATION
...
allocate( part_(pdim,is_:ie_) ) ! ARRAY ALLOCATION
...
subroutine exchanger_compute_bij(ierr,msg)
implicit none
...
part = 0.0_wp ! HERE CODE CRASHES
...
end subroutine
...
end module
Nothing seems wrong to me. The incriminated instruction is a fortran vector operation, should be fine. It crashes even when I compile with bound checking.
How can I determine the reason for this sudden crash? I hoped a core dump file, given to Totalview or some other debugger, could have helped..
I am using this port of FreeRTOS and I am loading it onto the Cortex-M3 within an OMAP4430. This works fine using the remote proc framework and I am able to use RPMsg to communicate with it.
Sometimes, however, rproc fails to load the elf and gives the following error:
rproc remoteproc1: bad phdr da 0x0 mem 0x10310
rproc remoteproc1: Failed to load program segments: -22
rproc remoteproc1: rproc_boot() failed -22
This seems to happen when the size of the elf file gets too large: this happens when the size is 377331 bytes but does not happen when I simply remove a bunch of print statements and bring the size down to 342563 bytes.
I have tracked the error message down to this piece of code: http://lxr.free-electrons.com/source/drivers/remoteproc/remoteproc_elf_loader.c?v=3.9#L188. It seems that rproc_da_to_va is unable to find a segment in memory large enough to fit the ELF.
How can I make sure that there is enough memory for the size of my ELF? Can I tell the kernel that I specifically want a certain region preallocated for this kind of thing? Is there some way to ensure that this part of my ELF remains small?
Thanks!
Make sure that the FreeRTOS configuration constants configTEXT_SIZE and configDATA_SIZE agree with the amounts demanded by your linker script. For example, if your linker script contains
MEMORY
{
TEXT (rwx) : ORIGIN = 0x00000000, LENGTH = 1M
DATA (rwx) : ORIGIN = 0x80000000, LENGTH = 1M
}
then you should set configTEXT_SIZE and configDATA_SIZE to 0x100000.