Is there a (hidden) flag, or any other way, to switch off the tearing algorithm in Dymola (2016 FD01).
I know, that there is a flag called Hidden.UseNewTearing, but I am not able to find any further hidden flags related to the tearing step.
No, that was removed with Dymola 5.3 a dozen years ago.
But more importantly - you should probably explain why you want to do that.
Related
I am integrating SQL-Connection to one or our existing Siemens S7-1200 PLCs right now.
After copying a Function Block from a working project, one of the data types has changed and is causing trouble now.
Original:
Copied FB:
Does anybody know, how to fix this?
Someone in the Siemens-Forum could answer my question right away.
Leaving his answer here for the next person with my problem :
With the introduction of the OUC library in version V4.x, the TCON instruction, among other things, has changed. Try to update the program on the CPU. In this case, the prerequisite is that the CPU must have at least firmware version V4.1. There is also the risk that translation errors will occur in other places where the older versions were previously used. In this case, the PLC code would have to be adjusted accordingly.
I would like to write a presolved problem into a file. Is there any way to do it?
write problem does not do it for me, it gives me the original problem that I read with SCIP.
The context is that I am working on SAT problems. The presolving phase of SCIP reduces the number of constraints and variables of the problem, effectively making the problem a little smaller. I would like to take a look at the presolved problem and compare it with the original problem and make some observations.
Yes, it is very easy, just use write transproblem.
The SCIP interactive shell also tells you all the possible commands that you can use, e.g. if you just type write in the SCIP shell, you see all available write commands
env: IDEA-14.0.2, kubuntu14.10 x64
Yesterday I use IDEA to learn source from Spark. When discussing with my partner, I write serval lines directly to the source, then I closed the IDEA without ctrl+S
Today when I open the project I found that those little changes still exist and make the source very dirty (and bit hard to remove them since they are everywhere). I assume that there's a autosave feature the avoid close without saving by incident.
how to close that on certain project? or do it globally?
Currently it can't be disabled. There are a few open issues in the IntelliJ's YouTrack, for instance IDEABKL-6460. There is a long discussion in this issue, but from comments like this:
Auto-saving is built in very deeply and many IDE features just won't
work without it (e.g. compilation, running, etc). For reverting
unwanted changes there's VCS, Local History and Undo.
Currently we don't plan to add a possibility to disable auto-save.
it seems that implementing this feature isn't planned and even if it was it would be probably difficult. But you can leave a comment and vote for the issue because the more people request this feature the more probable it is that it will get actually implemented sometime in the future.
I have a problem with several references in my VB.NET project.
For example I have this line of code:
Dim m As New Chilkat.Email
It comes from the library "ChilkatDotNet45.dll".
When I click on "References" and locate this dll, I can see that it has the settings "Use local copy" and "Do not include interop types".
When I switch to Release mode, the compiler tells me that "Chilkat.EMail" is not defined.
I have this problem with several DLLs, so it is not specific to Chilkat.
Can somebody tell me what I did wrong?
Thank you.
One of the standard approaches to solving any programming-related issue is trying to reduce the scope of the investigation. If you have a big project, in which something doesn't work, try to create a smaller project, and try to replicate desired functionality in it. Reduce as much as possible, down to a brand new project with maybe 5-10 lines of code in it.
If you were unable to solve your problem after making a reduced test case, now it's good time to post it on StackOverflow. I am usually reducing problems while writing a question on SO (not before, as one might think), constantly thinking "ok, is it minimized enough"; and this is how 90% of the questions never get posted - I often find a solution along the way of reducing my question to bare bones. :)
In your case, can you build a simplified project which has this problem and post a link here? We could then try switching Debug to Release on our machines and see if the we can reproduce. There are too many options to do the guesswork.
I am working on a legacy project that has a large amount of files dating back to pre-OS X days. It's data has been 16 bit aligned for > 15 years. I would like to move to a full LLVM compilation but I can't seem to get 2 byte alignment working. Are there any compiler level options available for this? (previously using -malign-mac68k)
I am aware of the #pragma pack(2) option here. However that would require me to modify upwards of 1000 source files to include this. That it's a worst-case option, but it seems like a hack. Besides, if this is possible then surely there is a default option to set the alignment?
According to clang's sources, it does support mac68k alignment rules. It seems that right now you can enable it via "#pragma options align=mac68k" only. If you're ok with small clang hacking, then you can implement the cmdline option as well and submit the patch to clang.
I would suggest looking at #pragma pack (see http://msdn.microsoft.com/en-us/library/2e70t5y1%28v=vs.80%29.aspx and http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html). It's relatively easy to use, and should work with any compiler Apple ships.
i use the latest gcc/gortran on osx compiled by the guys at ibm, if you read the gcc manual there are at least 8 different alignment optimizations to consider not just the bulk malign
Because system-level headers assume default alignment (they don't have directives to override alignment in most cases), changing the alignment for everything will break OS calls. As such, you don't want to be doing this.
Just write a script to apply your #pragma pack(2) to the source files in question, avoiding #includes. It's relatively easy and unlikely to cause unfortunate side-effects.