Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

External process

21 views
Skip to first unread message

Alexis EidelMan

unread,
Jun 18, 2013, 9:25:07 AM6/18/13
to liam...@googlegroups.com
Hi all,

I have implemented some code to run an external process. I let you know just in case you have idea to improve or if you're facing the same issue.
It's a process which need the data produced by liam (simulation as argument) but can't be written directly as common liam processes (because of complexity and because already done in an other way).
Adding it as an other process enable to benefit from the Liam frame.


In the process file I added:
class ExtProcess(Process):
    '''these processes are not real Liam2 processes
    The file containing the function should be in the path and
    the function itself must be named "main".
    '''

    def __init__(self, name, arg):
        super(ExtProcess, self).__init__()
        self.name = name
        self.args = arg

    def run_guarded(self, simulation, const_dict):
        context = EntityContext(self.entity, const_dict.copy())
        self.run(simulation, context['period'])
           
    def run(self, simulation, period):
        module = importlib.import_module(self.name)
        if self.args is not None:
            arg_bis = list(self.args)
            for index, arg in enumerate(self.args):
                if arg == 'period':
                    arg_bis[index] = period
                elif arg == 'simulation':
                    arg_bis[index] = simulation
                else:
                    arg_bis[index]= arg       
            arg_bis = tuple(arg_bis)   
            module.main(*arg_bis)
        else:
            module.main()

    def expressions(self):
        if isinstance(self.expr, Expr):
            yield self.expr


And in simulation:
          if ent_name == 'legislation':
                proc2 = ExtProcess('of',['simulation',2009,'period'])
                processes.append((proc2, 1))

Gaëtan de Menten

unread,
Jun 18, 2013, 10:47:07 AM6/18/13
to liam...@googlegroups.com

It seems like a good idea, but the implementation and the way you use it
is sub optimal. You should rather implement a new action (see
actions.py) and use it in your model instead of hard-coding the process
in Liam2.

Hope it helps,
Gaetan

On 18/06/2013 15:25, Alexis EidelMan wrote:

> I have implemented some code to run an external process. I let you know
> just in case you have idea to improve or if you're facing the same issue.
> It's a process which need the data produced by liam (simulation as
> argument) but can't be written directly as common liam processes
> (because of complexity and because already done in an other way).
> Adding it as an other process enable to benefit from the Liam frame.
>
> And in simulation:
> if ent_name == 'legislation':
> proc2 = ExtProcess('of',['simulation',2009,'period'])
> processes.append((proc2, 1))
>

>



----------------------------------------------------------------------------

Disclaimer: please see "www.plan.be/disclaimer.html"

Please consider your environmental responsibility before printing this email

----------------------------------------------------------------------------

Alexis EidelMan

unread,
Jun 18, 2013, 11:14:20 AM6/18/13
to liam...@googlegroups.com, g...@plan.be
To be honest, I don't understand very well.
Why is it sub-optimal ? What is the difference between processes and actions ?

If it was an action, i would be forced to have that process linked to an entity and I'd prefer not because it's really a process which must have the whole simulation as an argument. Changes on the rest of code are very light that way.
But if it's suboptimal I'll change.

Gaëtan de Menten

unread,
Jun 19, 2013, 4:25:29 AM6/19/13
to liam...@googlegroups.com

On 18/06/2013 17:14, Alexis EidelMan wrote:
> To be honest, I don't understand very well.
> Why is it sub-optimal ? What is the difference between processes and
> actions ?

Sorry, I was totally unclear. What I meant is that you should add your
new process kind to one of the "functions" dictionaries (I thought about
the one in actions.py) so that it is usable in your model and you keep a
sane separation between the model and the framework.

> If it was an action, i would be forced to have that process linked to an
> entity and I'd prefer not because it's really a process which must have
> the whole simulation as an argument.

All processes are linked to an entity, yours is no exception (you even
hard-code it to be linked to the "legislation" entity), but that does
not prevent you from passing the simulation as an argument as long as
you override run_guarded (like you have done).

> Changes on the rest of code are very light that way.
> But if it's suboptimal I'll change.

Hard-coding is always bad (at least when it is possible to avoid --
which is the case here).

Gaetan

> Le mardi 18 juin 2013 15:47:07 UTC+1, Ga�tan de Menten a �crit :

Alexis EidelMan

unread,
Jun 19, 2013, 5:24:34 AM6/19/13
to liam...@googlegroups.com, g...@plan.be
Thank you for having taken time to explane that point to a non-specialist like me.

Le mercredi 19 juin 2013 09:25:29 UTC+1, Gaëtan de Menten a écrit :

On 18/06/2013 17:14, Alexis EidelMan wrote:
> To be honest, I don't understand very well.
> Why is it sub-optimal ? What is the difference between processes and
> actions ?

Sorry, I was totally unclear. What I meant is that you should add your
new process kind to one of the "functions" dictionaries (I thought about
the one in actions.py) so that it is usable in your model and you keep a
sane separation between the model and the framework.

> If it was an action, i would be forced to have that process linked to an
> entity and I'd prefer not because it's really a process which must have
> the whole simulation as an argument.

All processes are linked to an entity, yours is no exception (you even
hard-code it to be linked to the "legislation" entity), but that does
not prevent you from passing the simulation as an argument as long as
you override run_guarded (like you have done).

> Changes on the rest of code are very light that way.
> But if it's suboptimal I'll change.

Hard-coding is always bad (at least when it is possible to avoid --
which is the case here).

Gaetan

> Le mardi 18 juin 2013 15:47:07 UTC+1, Ga�tan de Menten a �crit :

benbel

unread,
Nov 8, 2017, 6:14:28 AM11/8/17
to liam2-dev
Hi Gaëtan,

This is just to let you know that @benjello and me are going to reimplement this feature in the next few months.

Ben
Reply all
Reply to author
Forward
0 new messages