Basically, I want to optimize a process that includes a heater, a flash unit and a PFR. I've defined constraints for all the units, but don't quite understand how to incorporate the PFR dae model into the overall process model and solve for them together.
I would appreciate some explanation of the architecture of pyomo and how it can combine these models.
Thank you.
If you have those models, format a mathematical model first and define the decision variables and build your pyomo model.
Related
What is the best way to have model fields translated in Django? I've thought about adding extra fields to the model (one field per language) or creating another model with all texts in every language, is there a recommended way to achieve that?
Thank you very much
NB : I first voted to close this as primarily opinion based but then it struck me that there were actually technical reasons to choose one solution or the other...
Both approach are valid and as a matter of fact you'll find reusable django apps based on either one of the other.
Technically, there are pros and cons to each design.
Using distinct "translation" objects means you'll have an additional join or query (to get both the "master" model and it's translation(s)), but you have no overhead on the master model itself (without translation). Also, it makes create/update operations more complicated.
Using additional "hidden" per-language fields avoids the join / additional query overhead and keeps create/update operation simple, but makes records much bigger so it has some overhead wrt/ the database itself (page cache management etc) and the volume of data going back and forth between your django process and the database.
As a general rule, if you have to support a lot of languages and/or have to translate a lot of text fields for each model, you'll probably want to use a distinct model for translations, while if you have few languages and only a couple "translatable" fields per model the "hidden field" approach will be simpler to implement and will avoid the extra queries / joins.
As far as I'm concerned, I've had experience with both solutions and found the "hidden field" solution (using django-modeltranslations) to work fine for our current needs (four languages supported and we should not get much more, no more than =~ four translatable fields per model, and those models are rarely updated so we can cache aggressively if needed), but you may have totally different needs.
In all cases, don't even try implementing this from scratch, use one of the existing django apps instead, it will save you a lot of time and pain.
Check out their docs django translation
This will help too
Localization: How to Create Language Files - Python Django Tutorials
I Already have a Doc2Vec model. I have trained it with my train data.
Now after a while I want to use Doc2Vec for my test data. I want to add my test data vocabulary to my existing model's vocabulary. How can I do this?
I mean how can I update my vocabulary?
Here is my model:
model = model.load('my_model.Doc2vec')
Words that weren't present for training mean nothing to Doc2Vec, so quite commonly, they're just ignored when encountered in later texts.
It would only make sense to add new words to a model if you could also do more training, including those new words, to somehow integrate them with the existing model.
But, while such continued incremental training is theoretically possible, it also requires a lot of murky choices of how much training should be done, at what alpha learning rates, and to what extent older examples should also be retrained to maintain model consistency. There's little published work suggesting working rules-of-thumb, and doing it blindly could just as likely worsen the model's performance as improve it.
(Also, while the parent class for Doc2Vec, Word2Vec, offers an experimental update=True option on its build_vocab() step for later vocabulary-expansion, it wasn't designed or tested with Doc2Vec in mind, and there's an open issue where trying to use it causes memory-fault crashes: https://github.com/RaRe-Technologies/gensim/issues/1019.)
Note that since Doc2Vec is an unsupervised method for creating features from text, if your ultimate task is using Doc2Vec features for classification, it can sometimes be sensible to include your 'test' texts (without class labeling) in the Doc2Vec training set, so that it learns their words and the (unsupervised) relations to other words. The separate supervised classifier would then only be trained on non-test items, and their known labels.
I have generated two source code for two different model from training set for a classifier in Weka.
Is there any way through which I can combine these two different models generated from the same Weka Classifier?
Any suggestions or solutions would be of great help.
Thank you.
There are multiple ways to combine two or more classifiers into a single classifier. Weka offers schemes such as vote and stacking (weka.classifiers.meta). Boosting and bagging schemes (such as Adaboost) are technically also ways of combining multiple classifiers into one, but they typically work around a single type of classifier and help you train it more intensively.
When using vote you can include multiple classifiers, each of which assign a class to an instance. Vote itself will assign the class that was assigned most often. Stacking trains a meta classifier over the included classifiers. In a way it helps you train a way of interpreting multiple classifications.
You can accomplish that in the Weka Explorer (classification tab), by selecting the pre build models under preBuildClassifiers, or setting them in your code with setPreBuiltClassifiers.
I would like to do bidirectional Model2Model transformations. Both models are EMF / eCore based. Actually I would prefer that one model is an editable view on the other.
What are my options?
Which tools and tranformation languages are avaiable and what are their restrictions?
M2M are the hardest. Industries strength tools are rare, lots of academia stuff. If you're dead set on a M2M language, look into ATL which should also support ecore. Otherwise you can look at Xtend, which was made for model to text but you can abuse it and it should be more comftable than plain java. If your into research look at Scala based transformations here
http://metrikforge.informatik.hu-berlin.de/attachments/download/193/george_wider_scheidgen_ICMT_2012.pdf
There are more transformation tools than you can imagine for EMF, its kind of crazy...
For metamodel to metamodel transformation where the models are not very similar:
ATL is probably the most popular and most "baked"
Epsilon project has the Epsilon Transformation Language.
If the metamodels are very similar and you only need to tweak some things then there are tools targeted that type of migration/updating:
ATL now has a refining mode
Epsilon has Flock
Edapt looks very interesting as well because it does the metamodel/model changes together. It lets you work on a tree view and comes with a set prebuilt set of rules.
Henshin which lets you operate on a diagram view of the model
EMF Refactor is a more code-level approach, that can also use Henshin rules somehow.
You can always directly manipulate the metamodel and model using the EMF Java APIs as well.
I'll add, if you are doing any real EMF work you will need to get and read EMF: Eclipse Modeling Framework. It's available in Safari also. I highly recommend Safari, for $39 a month you get almost every development ebook you could ever use.
If you insist on doing bidirectional M2M transformations, (so-called Bxs), then know that there is an active researcher's community updating that wiki : http://bx-community.wikidot.com.
If you visit it, you will find that they list a bunch of tool suitable for Bx transformations http://bx-community.wikidot.com/relatedtools.
I used ECHO in the past which provides an implementation of QVT-R based on the KodKod constraints solver.
It's definitely worth giving it a try.
Since you specifically asked for bi-directional model transformations, I must say that you have no options. To make it claer, adding to the answer you got form Ed Willink, none of the existing M2M transformation languages (AFAIK) supports bi-directional model transformations.
Work on a QVTr and QVTc execution engine is starting to look promising if you are still interested in this: QVTd Project.
For my project report, i need to show the class diagram of the software i've built which counts around 20 classes! The problem, is that when i render the class diagram in jpeg file(either using StarUML or ArgoUMl or whatever..) we can't see the details correctly (very big picture because of the large number of classes). Well, how to manage this situation correctly? Since the report is gonna be printed on A4 pages ?
Thanks !
With 20 classes I would expect at least 3 subsystems, (modules, layers), possibly more
Make package diagram showing the relation between those, one class diagram for each subsystem.
Add class diagrams for special things you want to show. Print each on A4.
If you can't split the diagram easily into modules, I'd consider that a design smell.
Its fun to print large diagrams on huge pieces of paper (like 500 tables on A0 ;-) but it really isn't of much use.
Producing a class diagram containing 20 classes is totally useless- what does it actually show? When using class diagrams I've never created a diagram that has more than about 5-8 classes on it.
The question to ask yourself is "what useful information am I trying to show with this diagram?". Don't produce a class diagram for the sake of it!
Breaking it down to demonstrate a particular design pattern, subsystem or component is what I find class diagrams useful for.
an other way is to not show all members but only the main ones, this reduce the size of the classes then the size of the diagram. Of course this suppose you use a tool allowing to choose which operations/attributs/relations must be visible, but this drawing setting is classical
may be you tool also have drawing setting to hide some part of the operation to reduce the width, for instance to show or not the parameters, or their direction, their type etc
Bouml (http://bouml.free.fr) has all this drawing options, and as it was said has PNG and SVG exports
best regards and happy modeling
Bruno
There are a few things you can do:
Bigger paper
Don't display method signatures
Don't display private methods
Partition your problem into more packages
Fewer classes per diagram
This is one of the problems with trying to treat UML like engineering drawings: Once you get it off a whiteboard, it's a poor language for communication. It doesn't read so well.
Generally a good way to deal with this is to create different diagrams for different modules or areas of functionality for your software. Alternately you could print the single image on multiple pages and show how to assemble them to form the full image.
I think it's the inherent problem that you're trying to show so many things in one diagram. Your question is just like "how can I put 100 words in a sentence without the reader getting tired of it?"
You can probably refactor it with FacadePattern. Basically it's just breaking down stuffs into modules. For e.g. Timesheet, PayCheck, BonusRecord can be ground into ManagementSystem. Product, Order can be grouped into OperationSystem, etc.
Use BOUML. The ArgoUML and StarUML are classics which everybody mention when it comes to question "is there any free UML software?". It's funny that being a historic software does not make the software unknown and unused. In case of Argo and Star the historic coefficient makes them known and used.
BOUML can export to SVG. This will solve your problems.I described the tool here
Thanks to SVG you will be able to quickly switch between birds eye view and detail view. I do this with Firefox. It's rapidly fast.
PS. I just noticed that you want to print the report. The SVG is then probably not what you want :\
Split your classes in several diagrams! When creating a UML model, you can have model elements such as classes displayed (no not) in several diagrams. A diagram is just a view of your UML model so that you can highlight modules in your specific diagrams.