I started working with OpenModelica a week ago. I am working mainly with OpenModelica Connection Editor. My goal is to simulate some pumps, tanks and control logic.
I put all the elements on the diagram view and I tried to set up everything in parameters tab, but I found out that I do not have same input fields as my colleagues?
When I open pump or tank parameters I do not have Medium input field (please see attachment).
When I open pump I do not have flow or efficiency characteristic (please see attachment).
I tried to solve this problem by simply adding Medium in text view, but then I got errors on not declared density or translation error that medium is not in the scope.
I tried to reinstall the program, but with no luck.
Could you kindly help me with this? Is there any way to turn on those fields? To be honest I am not even sure how much more fields I am missing.
The medium package is declared as replaceable package so that its component type can be changed in the future. About 2 years ago in OMEdit redeclaration of medium packages can only be changed in the text layer due to various reasons as reported in https://trac.openmodelica.org/OpenModelica/ticket/2079. But now redeclaration can be implemented from the UI level similar to the dropdown list feature in Dymola.
Goto Tools--> Options --> General --> Optional features --> check 'Enable Replaceable Support'--> Press 'OK'
Note: Restart OMEdit once you do the above steps.
Now you can see the see 'Medium' selection in the Parameters window!!!
When you are playing with fluid components make sure that all of the connected models are having same medium type.
Related
We can have 4-5 people signing contracts at once, and are currently using the 'setShared' function to share text across all signing experiences for each client. However, when we use this, the text on the final contract comes out very blurry because the text layers get stacked on top of each other.
Sample text here:
I don't think setting Shared property is causing the problem. If you are setting the bold property on the tab then I suggest removing it. Also trying changing the font/fontSize properties to get the result you are expecting.
We want to "Categorize" our work orders more systematically. So far, we've been using Description, but we feel it is not a reliable way. We were hoping to use Failure Class as a starting point, but we find that having on a different tab discourages technicians and the help desk from classifying the work order.
Is it possible to add/duplicate the Failure Class field to Work Order Tracking screen?
Normally, I wouldn't ask, but was not clear if this was possible because Failure Class, Codes, and Tracking are different tables in Maximo. So, I wasn't sure how this would work exactly...
The simple answer is to use Application Designer's copy / paste functionality to duplicate the field. The specific field in question is on the top level of the Work Order Tracking application and facilitates interaction with the FAILURECODE attribute of the Main Object of the application, which is WORKORDER. Therefore, a copy / paste operation should be all you need. (Note: Application Designer's copy / paste functionality is used via that application's toolbar buttons, not Ctrl+C / Ctrl+V.) And if using Application Designer's copy / paste functionality doesn't work to your satisfaction, I would recommend exporting the XML for the application, copying the line of XML as desired and giving it a unique id, and importing the updated XML back in to Maximo. (Application Designer has toolbar buttons for exporting and importing an application's XML.)
You mentioned difficulty getting users to fill it in as a driver for asking the question. Another solution, which you can do as well as or instead of copying the field, is to specify the Failure Class on each Asset. Then, when an Asset is put on a Work Order, its Failure Class will be copied over, saving the users work and risk of not choosing correctly. And another idea is to highlight the Failure tab until a Failure Class is supplied.
And you also mentioned that the driver behind getting them to fill in the Failure Class, and etc, was to help categorize work. To that point, you should know that Failure Classes, in specific, and Failure Codes, in general, are intended to be used to help you determine what's going wrong with your assets, how often, and how the problems are being fixed. So, using them to categorize work is a bad idea. Instead, you should be using the Work Type field and Classifications, because categorizing work is what these are meant to be used for. The Work Type field is already on the Work Order tab, and Classifications fields are on the Specifications tab. You could copy the Classifications fields the same as I directed above for the Failure Class field.
I am using KOLite on a project, and have everything working properly. The activity indicator works perfectly inside a button or in a small area.
My question is: Is there a way to configure the activity indicator per binding? For instance, it would be nice to have a large indicator in a div while records are loading, etc.
I hate to use a different indicator in certain places.
The one in kolite hooks into the control you nbind it to. However, you could create your own activity indicator for the page (or region) and wire up the code to turn it on and off in your kolite commands' completed handlers. Its a bit more custom, but there's nothing wrong with that.
I have the following Message-level entry in my Error List from CodeContracts:
CodeContracts: Checked 410 assertions: 404 correct (6 masked)
I can't figure out:
What masked assertions are
How to locate the 6 that it mentions
Whether or not I should be concerned about them
Sorry for not posting code... I have no idea how to recreate this in a small sample :)
Many thanks
It's simple, in your project properties>Code Contracts>Static Checking> put the warning at "hi".
Now ccCheck made more warning.
Bye.
These seem to be assertions that are masked by virtue of their inclusion in the "baseline" file. From the documentation (emphasis mine):
6.6.8 Baseline
Bringing an existing code base to a point where the verier emits only a few warnings is dicult and time consuming, as it requires adding numerous contracts. To make it easier to use contracts on existing code bases, and to focus warnings introduced by new code or code changes, the Baseline functionality can be used.
To use the baseline functionality, check the box labelled Baseline and provide a file name to store the baseline in. The path is relative to the project output directory. When the analysis is run and the baseline file does not exist, the baseline is created. During this run, all warnings are shown in the output and stored in the baseline file as XML.
When the analysis is run and the baseline file exists, then the baseline acts as a filter and warnings already found in the baseline are not shown again. New warnings are shown and stored in a file called <baseline>.new, where <baseline> is the file name of the baseline file. Since the files are stored as textual XML, it is possible to edit them and to add additional failures to the baseline. The format does not depend on method ordering and additional XML tags for grouping can be introduced freely.
I was wondering about the "masked" messages, too; I turned off the "baseline" option, and they no longer appeared. The answer to your second question therefore seems to be "clear the 'baseline' check box."
As to whether you should be concerned about them, I would say, yes, you should.
I'm probably using the wrong terminology but basically I would like to dump the findings from the panel to the right of the scrollbar to a file for later review. See the screenshot below for what I mean. It's the part of the screen with the orange and green lines on. Does anyone know if this is possible?
If anyone is interested I have filed a feature request for this with JetBrains here.
As far as I know it's not possible, at least with the built in features. Maybe it's possible by writing a plugin.
The only thing which I know to get something like this:
Goto the 'Code Issues' Inspector: Resharper->Code Issues in Current Solution or any other of these options
On the window which shows the issues is a 'Export' button. With that button you can export the issues of the project/solution/file.
The report format is pretty simple list of issues as text. Like this:
5 issues found
Common Practices and Code Improvements (1 issue)
<DemoApp>\Program.cs (1 issue)
Property 'Title' can be made private
Potential Code Quality Issues (4 issues)
<DemoApp>\Program.cs (4 issues)
Auto-implemented property accessor is never used
Auto-implemented property accessor is never used
Class 'Comment' is never instantiated
Class 'Program' is never instantiated
It's now possible to use Resharper's Command Line to produce a xml with the issues on a given solution.
It's not exactly the 'export' functionality you wanted, but it might be useful still.
You just have to run the tool and pass the file where it will save the issues. For example:
inspectcode /o="D:\Resharper\MyIssues.xml" [PathToSolutionFile]
I've noticed this produces more issues than the plugin inside Visual Studio does, for some reason. I really think the Resharper's team should concentrate on using the same code to analyze the files instead of different implementations like it seems to be now.