Simulating energyplus with the BCVTB interface - energyplus

I have a openstudio model with 3 zones. We are using a python program to execute energyplus with the BCVTB interface. I got it to work on thermal zone 3 but not for thermal zone 1 and 2. I have the input variables defined in variables.cfg as: as:
<variable source="Ptolemy">
<energyplus <EnergyPlus schedule="Cooling TZ2 Setpoint Schedule"/>
</variable>
<variable source="Ptolemy">
<energyplus <EnergyPlus schedule="Heating TZ2 Setpoint Schedule"/>
</variable></variable>
But when I run the execution I seem to get no load on the Air Loop for thermal zone 2. I have a plant loop for district heating and district cooling and then Air Loops thermal zone 2.
Could use some help with this.
The Osm and idf file can be found here: https://drive.google.com/file/d/1TM6LfmL8KI7w0XFswB9GMTH-KJQE5D-m/view?usp=share_link
Output from energyplus:
Program Version,EnergyPlus, Version 22.1.0-ed759b17ee, YMD=2022.12.20 10:42,
************* Beginning Zone Sizing Calculations
** Warning ** SetUpDesignDay: Entered DesignDay Barometric Pressure=31000 differs by more than 10% from Standard Barometric Pressure=100201.
** ~~~ ** ...occurs in DesignDay=SIZING PERIOD DESIGN DAY 1, Standard Pressure (based on elevation) will be used.
** Warning ** ProcessScheduleInput: Schedule:Compact="ZONE CONTROL TYPE SCHED TZ2", Schedule Type Limits Name="ANY NUMBER" not found -- will not be validated
** Warning ** ProcessScheduleInput: Schedule:Constant="ALWAYS OFF DISCRETE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Constant="ALWAYS ON CONTINUOUS", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Constant="ALWAYS OFF DISCRETE 1", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Constant="ALWAYS ON CONTINUOUS 1", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** GetHTSurfaceData: Surfaces with interface to Ground found but no "Ground Temperatures" were input.
** ~~~ ** Found first in surface=SURFACE 7
** ~~~ ** Defaults, constant throughout the year of (18.0) will be used.
** Warning ** CheckUsedConstructions: There are 6 nominally unused constructions in input.
** ~~~ ** For explicit details on each unused construction, use Output:Diagnostics,DisplayExtraWarnings;
** Warning ** Calculated design cooling load for zone=THERMAL ZONE 2 is zero.
** ~~~ ** Check Sizing:Zone and ZoneControl:Thermostat inputs.
** Warning ** Calculated design heating load for zone=THERMAL ZONE 2 is zero.
** ~~~ ** Check Sizing:Zone and ZoneControl:Thermostat inputs.
************* Beginning System Sizing Calculations
** Warning ** ManageSizing: Calculated Cooling Design Air Flow Rate for System=AIR LOOP CLG TZ2 is zero.
** ~~~ ** Check Sizing:Zone and ZoneControl:Thermostat inputs.
** Warning ** ManageSizing: Calculated Heating Design Air Flow Rate for System=AIR LOOP CLG TZ2 is zero.
** ~~~ ** Check Sizing:Zone and ZoneControl:Thermostat inputs.
** Warning ** ManageSizing: Calculated Cooling Design Air Flow Rate for System=AIR LOOP HTG TZ2 is zero.
** ~~~ ** Check Sizing:Zone and ZoneControl:Thermostat inputs.
** Warning ** ManageSizing: Calculated Heating Design Air Flow Rate for System=AIR LOOP HTG TZ2 is zero.
** ~~~ ** Check Sizing:Zone and ZoneControl:Thermostat inputs.
************* Beginning Plant Sizing Calculations
** Severe ** SizeAirLoopBranches: AirLoopHVAC AIR LOOP CLG TZ2 has air flow less than 1.0000E-003 m3/s.
** ~~~ ** Primary air system volumetric flow rate = 0.0000 m3/s.
** ~~~ ** Check flow rate inputs for components in this air loop and,
** ~~~ ** if autosized, check Sizing:Zone and Sizing:System objects and related inputs.
** Fatal ** Previous condition causes termination.
...Summary of Errors that led to program termination:
..... Reference severe error count=1
..... Last severe error=SizeAirLoopBranches: AirLoopHVAC AIR LOOP CLG TZ2 has air flow less than 1.0000E-003 m3/s.
************* Warning: Node connection errors not checked - most system input has not been read (see previous warning).
************* Fatal error -- final processing. Program exited before simulations began. See previous error messages.
*************
************* ===== Final Error Summary =====
************* The following error categories occurred. Consider correcting or noting.
************* Nominally Unused Constructions
************* ..The nominally unused constructions warning is provided to alert you to potential conditions that can cause
************* ..extra time during simulation. Each construction is calculated by the algorithm indicated in the HeatBalanceAlgorithm
************* ..object. You may remove the constructions indicated (when you use the DisplayExtraWarnings option).
*************
************* EnergyPlus Warmup Error Summary. During Warmup: 0 Warning; 0 Severe Errors.
************* EnergyPlus Sizing Error Summary. During Sizing: 14 Warning; 0 Severe Errors.
************* EnergyPlus Terminated--Fatal Error Detected. 14 Warning; 1 Severe Errors; Elapsed Time=00hr 00min 0.14sec
Thanks
I tried to run a simulation of the 3 thermal zones building using the BCVTB interface of energyplus. I expected the simulation to work since I defined the input variables in the variables.cfg file.

Related

How to check in SystemVerilog that signal went high during simulation using ModelSim

I need to check, whether during the testbenching the particular signal went at least for a single clock cycle to logic 1.
I've tested following asserts, which shall be equivalent:
initial assert property (
#(posedge clk_tree_x.ClkRsBST_ix.clk)
s_eventually TS.TSUpdated) else
$error("Was not active");
and
initial begin
assert property (#(posedge clk_tree_x.ClkRsBST_ix.clk)
strong(##[*] TS.TSUpdated)) else
$error("Was not active");
end
In simulation using Mentor ModelSim SE64 2021.1 the results are extremely weird.
On first simulation pass the simulation completely ignores this assert. On second simulation pass ModelSim apparently uses results of previous simulation to announce before even the newly run simulation happens that the assert triggered:
# Time: 2005087500 ps Started: 5 ns Scope: tb_bst_provider.DUT.fook File: bst_provider.sv Line: 669
# ** Warning: (vsim-8777) Breakpointing based on severity while evaluating concurrent assertion is not supported.
# Time: 2005087500 ps Iteration: 0 Region: /tb_bst_provider/DUT File: bst_provider.sv
Not sure whether this is consistent behaviour to all strong properties, but it is hardly useful for any sort of unit testing, as the tests never run twice using the same parameters.
Is there any way how to assert that 'signal is not present through the simulation run', which actually works with modelsim?
I am not sure if you can do it with an assertion. You can detect not active signal using an assertion coverage. In any case you should not place an assertion in the initial block.
Potentially checking for activity can be done without using an assertion as in the following example.
always #(posedge clk) begin
if (sig == 1)
active <= 1;
end
final begin
if (!active)
$error("was not active");
else
$info ("it was active");
end
Just make sure that you have a normal exit from simulation or final might not be executed at all in case of interrupts.

arm64 ptrace SINGLESTEP: are the steps described in this paper correct?

I was reading the paper Hiding in the Shadows: Empowering ARM for Stealthy Virtual Machine Introspection and I was wondering whether the steps they are described in paragraph "2.3 Debug Exceptions" were correct or not:
AArch64 allows to generate Software Step exceptions by setting the SS
bit of the Monitor Debug System Control MDSCR_EL1 and Saved Program
Status Register SPSR of the target exception level. For instance, to
single-step a hit breakpoint in EL1 the monitor must set the
MDSCR_EL1.SS and SPSR_EL1.SS bits. After returning to the trapped
instruction, the SPSR will be written to the process state PSTATE
register in EL1. Consequently, the CPU executes the next instruction
and generates a Software Step exception.
I have tried to understand how single-stepping happens in freeBSD, and I am noticing a mismatch.
I am basing the following lines of code to the release 12.3.0 of freeBSD (4 December 2021), commit: 70cb68e7a00ac0310a2d0ca428c1d5018e6d39e1. I chose to base this question on freeBSD because, in my opinion, following its code is easier than Linux, but the same principles shall be common to both families.
According to my understanding, this is what happens in freeBSD:
1- Ptrace single step is invoked, arriving in the architecture-independent code proc_sstep(), in sys_process.c:
int proc_sstep(struct thread *td)
{
PROC_ACTION(ptrace_single_step(td));
}
2- Architecture-dependent code ptrace_single_step()is called, in arm64/ptrace_machdep.c:
int ptrace_single_step(struct thread *td)
{
td->td_frame->tf_spsr |= PSR_SS;
td->td_pcb->pcb_flags |= PCB_SINGLE_STEP;
return (0);
}
Here single step bit (number 21) is set in the "Process State" of the tracee (tracee = thread that is traced) and a flag is set.
3- After a while, the traced task will be selected for scheduling. In cpu_throw() of swtch.S (where the new thread takes place), the flags of the new thread are checked, to see if it must single step:
/* If we are single stepping, enable it */
ldr w5, [x4, #PCB_FLAGS]
set_step_flag w5, x6
4- set_step_flag macro in defined in the same swtch.S:
.macro set_step_flag pcbflags, tmp
tbz \pcbflags, #PCB_SINGLE_STEP_SHIFT, 999f
mrs \tmp, mdscr_el1
orr \tmp, \tmp, #1
msr mdscr_el1, \tmp
isb
999:
.endm
Here, if the single-step flag is set, it sets the single step bit of register MDSCR_EL1 (bit in position 0).
4- To the best of my understanding, the combination of single step bit on SPSR_EL1 of the "Pstate" + single step bit on MDSCRL_EL1 implies that the tracee execute 1 instruction and it traps.
5- Trap is recognized as a EXCP_SOFTSTP_EL0 and it is handled in do_el0_sync() function of trap.c:
case EXCP_SOFTSTP_EL0:
td->td_frame->tf_spsr &= ~PSR_SS;
td->td_pcb->pcb_flags &= ~PCB_SINGLE_STEP;
WRITE_SPECIALREG(mdscr_el1,
READ_SPECIALREG(mdscr_el1) & ~DBG_MDSCR_SS);
call_trapsignal(td, SIGTRAP, TRAP_TRACE,
(void *)frame->tf_elr, exception);
userret(td, frame);
break;
Here, all the flags are reset and the traced thread receives a SIGTRAP (sent by itself, I think). Being traced, it will stop. And the tracer, at this point, can return from a possible waitpid().
What I could observe differs from the paper explanation. Can you check and correct the steps that I listed, please ?

what's func_info in eBPF verifier?

I'm developing an XDP program and I'm facing this error when trying to mount it in NIC driver:
libbpf: failed to guess program type based on ELF section name '.text'
libbpf: supported section(type) names are: socket kprobe/ uprobe/ kretprobe/ uretprobe/ classifier action tracepoint/ tp/ raw_tracepoint/ raw_tp/ tp_btf/ xdp perf_event lwt_in lwt_out lwt_xmit lwt_seg6local cgroup_skb/ingress cgroup_skb/egress cgroup/skb cgroup/sock cgroup/post_bind4 cgroup/post_bind6 cgroup/dev sockops sk_skb/stream_parser sk_skb/stream_verdict sk_skb sk_msg lirc_mode2 flow_dissector cgroup/bind4 cgroup/bind6 cgroup/connect4 cgroup/connect6 cgroup/sendmsg4 cgroup/sendmsg6 cgroup/recvmsg4 cgroup/recvmsg6 cgroup/sysctl cgroup/getsockopt cgroup/setsockopt
libbpf: load bpf program failed: Invalid argument
libbpf: -- BEGIN DUMP LOG ---
libbpf:
number of funcs in func_info doesn't match number of subprogs
processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0
libbpf: -- END LOG --
libbpf: failed to load program '.text'
I searched and found the error is raising when eBPF verifier trying to compare attr->func_info_cnt and env->subprog_cnt but I don't understand how these two values are set before processed by the verifier. I have one XDP program with one section and 6 functions as helpers, I'm not sure if this info can help but I can provide more about the structure of the program if needed.
Did you omit to put your programs in a dedicated ELF section? Something like:
SEC("xdp")
int my_prog(struct xdp_md *ctx)
{
...
}
(Where SEC() is a macro defined in libbpf's bpf_helpers.h header.)
If you do not specify any ELF section name, clang/LLVM defaults to .text, as in your error message. When you attempt to load a program with libbpf, the library usually guesses the program type from the name of the ELF section into which the program was put. If you do not use a dedicated section name, and do not otherwise specify the program type (for example, in libbpf with bpf_program__set_type()), then libbpf is unable to pick the relevant type for your program.
This could lead to some of your programs to fail to load. From the error message above, it looks like you use function calls in your program (instead of declaring, for example, your functions as static inline). When your main program passes the verifier, some parts will be missing: The “functions” may not be loaded, so the verifier complains that the expected number of functions/subprograms inferred from the main program (env->subprog_cnt) is different from the number of functions collected by your loader application (attr->func_info_cnt) and passed down to the kernel when loading the program with the bpf() system call.
If this is the case, you can probably fix the issue either by placing your code in dedicated ELF functions, or by declaring your functions as static inline if you do not require function calls in the generated bytecode.

Asynchronous Parallel Computing in MATLAB?

I am looking to utilize the labSend, labReceive functionality with spmd in MATLAB to execute perform the following:
Lab1, run a global optimization routine and pass an intermediate result to Lab2
Lab2, wait for the intermediate result from Lab1 (using labProbe), once received use this result and begin a new optimization routine.
Lab3,4,..., n wait for the previous result from Lab_n-1, once received use this result and begin a new optimization routine.
Problem:
Warning: An incoming message was discarded from lab 1 (tag: 1)
Warning: An incoming message was discarded from lab 1 (tag: 1)
Warning: An incoming message was discarded from lab 1 (tag: 1)
Warning: An incoming message was discarded from lab 1 (tag: 1)
Warning: An incoming message was discarded from lab 1 (tag: 1)
Data from labSend:
0.4907 0.3328 0.3625 0.5843 0.3159 0.5065 0.5100 0.4984 0.3336 0.5055
0.5216 0.5268 0.5002 0.4828 0.4907 0.3328 0.3625 0.5843 0.3159 0.5065
0.5100 0.4984 0.3336 0.5055 0.5216 0.5268 0.5002 0.4828 0.5010
which is in order with 0.4907 being the first message sent via labSend.
Last value received from labReceive:
0.5055
meaning the last 5 messages from labSend were ignored.
Now, the spmd routine is asynchronous as it 1) has to wait for the intermediate result of the previous lab and 2) the optimization routine speeds up as it progresses (searching a smaller domain)
Therefore, the previous labs may send multiple messages before lab_n has the chance to process them (executing something else).
Question:
Is there a way to immediately process (receive) data from Lab1 if I am looking at Lab2 and just store it somewhere? Or is there a way to process only the most recent message? and ignore any queued messages?
Thanks for your help!

Simulink: Selected signal originates from an unconnected source

I have a bit of an annoyance rather than a major problem, that I would like to tackle. I have a subsystem that creates a bus inside it and outputs it via a Scope. The bus creation is through From tags, that depend on signals from other components.
Now, when I don't have those components, I get a warning saying something like:
Warning: Selected signal 'Compressor' in 'untitled/Pressure/Bus Selector'
originates from an unconnected source signal
entering 'untitled/Output Data/Bus Creator12' at input port 1
It seems there is no way to turn this off in the Diagnostics pane (Connectivity sub-pane or otherwise). It seems it was a bug in very old versions of Matlab, but was fixed in R13, according to these links:
Link 1,
Link 2 (search for "unconnected source signal" on the page)
I'm using 2013a, a full 12 years later. Anyone have more information on how I can turn this warning off?