RiverWare Initialization Rules Don't Execute - modeling

A RiverWare initialization rule wasn't executing, even though it worked fine as a regular rule. Rule appears to be ineffective.
The rule references an expression slot for a historical diversion schedule.

Expression slots are not calculated until after initialization rules execute, so, in this case, the slot had no data, and the rule was ineffective.
You can correct this problem by creating a normal slot for the rule to use, which you can fill with input values by copying from the expression slot, or assigning values using an initialization rule that performs the same calculation as the expression slot.

Related

PDDL2.1: Purpose of `over all`

I'm working with PDDL2.1 durative-actions and I'm having difficulty understanding the purpose of over all.
I have a function charge_level which is updated with a value every 10Hz. In a durative-action move, I say condition: (over all (>= (charge_level) 12)).
I interpreted this as "while performing the action, verify that charge_level is greater than or equal to 12, otherwise, move fails and the planner should find a new action with the condition at start (< (charge_level) 12)". However, the planner does not seem to plan that way. I appreciate any clarity on this.
Thanks!
The semantics of the over all condition is indeed as #haz says in his answer (it prevents the planner from scheduling another action in parallel with your move action that would violate the over all condition), but what I think is confusing you is the difference between planning and plan execution. During plan execution, the (charge_level) may drop below 12 at any point unexpectedly due to malfunctioning battery, or faulty sensor, etc.. At such occasion, your plan execution should stop the move action (and therefore the whole plan) and re-plan. At that point, the planner could choose any action, which has a satisfied pre-condition in that new state. So not necessarily at start (< (charge_level) 12).
The PDDL durative action cannot be stopped or paused by the planner, while computing the plan. However, if you tell the planner, how is the (charge_level) changing over time, it could compute the longest possible duration of the move action, and then do something else e.g. recharge battery, before scheduling another instance of the move action into the same plan. In that approach, there are no failures involved, just reasoning about how long a given action could last in order to achieve the goal without violating any constraints, including the over all conditions.
If that is the behavior you want, you will need to model the (charge_level) as a continuously changing function. If you want to see an example, here is the power generator or the coffee machine. Here is a peek from the Generator domain:
The generator must not run out of fuel:
(over all (>= (fuel-level ?g) 0))
The fuel decreases by 1 unit every unit of time #t.
(decrease (fuel-level ?g) (* #t 1))
Given the initial (fuel-level), it is a simple calculation to figure out the maximum duration of the action. For that flexibility, you will need to specify the action duration unconstrained :duration (>= ?duration 0), as in the coffee machine domain.
Now, to be able to process such model including continuous numeric effects, you will need a planner that supports the :continuous-effects requirement, so for example OPTIC, or POPF.
If you just want to prevent the action from happening based on a condition, then you use at start. The over all is for conditions that must hold for the full duration of the action. So you could interpret your condition as, "for the entire duration of moving, never let the battery level go below 12".

Block Resource in Optaplanner Job scheduling

I've managed to use the Job scheduling example for a project I'm working on. I have an additionnal constraint I would like to add. Some Resources should be blocked sometimes. For example a Global renewable Resource shouldn't be used between minutes 10 to 20. Is it currently already doable or if not, how can it be done in the score calculation ?
Thanks
Use a custom shadow variable listener to predict the starting time of each task.
Then simply have a hard constraint to check that the task won't overlap with its blocks.
Penalize the amount of overlap to avoid a "score trap".

Activity Diagram how to continue code flow in one chart

I have a function.
Which for example goes like this:
Function start:
...
if statement{
set variable
}
if second if{}
contintue
This code I try to put into a UML, Activity diagram.
I wondered if my forking is done right, or do I need to use a forking symbol. So I have a split where it eventually gets into the if statement ( difference in totals). But after the if (or even if the if is not even executed) the next if statement will be executed (regardless of first if result).
If you want to have conditional paths you need to use decision nodes. Imagine a virtual token to represent the execution flow. When you are at an action that has multiple (unguarded) control flows leaving it, each will take a token (the UML spec calls that implicit fork) an execution will continue in parallel. So either you add guards to each of the outgoing control flows or you use a decision node. Though you should (or better must) use guards here too you have only a single token that will leave the decision node. Without proper guards it will be undecided which of the outgoing flows will take the token.
Implicit fork:
Only one token continues:
One token for sure and eventually a 2nd in parallel:
(I'm not 100% sure if that's really true. It's a notation I'd never use.)
Only one token continues, but not defined which (due to no guards):

What is the Difference between ConditionPathExists= and ConditionPathExists=| in systemd?

I need check a file not exist before i start my service in Systemd. I see two case in [Unit]:
ConditionPathExists=!/tmp/abc
and
ConditionPathExists=|!/tmp/abc
are they the same? Can anybody help me explain if they are different?
Sometime you specify multiple files like:
ConditionPathExists=!/tmp/abc
ConditionPathExists=!/tmp/abe
Now if any of the condition isn't satisfied, it doesn't start service. It's like and operations.
Now if you use:
ConditionPathExists=|!/tmp/abc
ConditionPathExists=|!/tmp/abe
If any of these conditions is satisfied, it will run the service.
Condition checks can be prefixed with a pipe symbol (|) in which case
a condition becomes a triggering condition. If at least one triggering
condition is defined for a unit, then the unit will be executed if at
least one of the triggering conditions apply and all of the
non-triggering conditions
It's like OR operations

JCL Return code FLUSH

//STE1 IF RC EQ 1 THEN
....
//ENDIF
the return code is giving me FLUSH and all the other job is not executing becaue of this
can anyone help me on this.
is it because i havent given ELSE?
If you have conditions for running steps, either COND or IF, and the condition determines that a step is not run, then there is no "Return Code" from the step. The step is not run, it is FLUSHed, so there is no RC.
If the rest of the steps in your JOB are expecting to run on a RC=0, then you will have to change something.
Consult the JCL Reference, you have other options, like EVEN, ONLY, but these may not suit (haven't a clue, as don't know exactly what you are trying).
//STEPA
...
//STEPB
...
//STEPC
If STEPB depends on STEPA, so will not run with a zero RC from STEPA, you need to decide what is needed for STEPC. You have three situations: STEPB not run; runs with zero RC; runs with non-zero RC. What should STEPC do in each case.
If STEPC has no conditional processing, then it will just run whatever happens to STEPB (except an abend, and no EVEN).
If STEPC needs to run conditionally, you have to decide what it is about STEPA and STEPB which tells you how to run it.
If your JOB is big, and the conditions are complex, consider splitting it into separate JOBs and letting the Scheduler take care of it.
If your JCL is destined for Production, there should be JCL Standards to follow, and if you are unclear how to do something, you should consult those responsible for the Production JCL, they will tell you how they want it, and whether you even need be concerned about it (as they may well just re-write from scratch anyway).
When a particular step in a JOB is skipped due to COND parameter or any other reason, what will be the retuen code that will displayed in the spool

Resources