COBIA EnergyPort Class

[ahmedsabriz]

Greetings,

I am stuck at implementing a COBIA energy port class for unit operation. For context, I am experimenting with a simple heater. the unit runs and solves correctly. However, my energy stream has no data. I would like to expose the duty from my calculations to the stream data.

Referring to CO_Unit_Operations_v6.25 document, I have doubts about the following part:

Energy Objects that connect to Energy Ports are expected to expose an ICapeCollection of
parameters, analogous to the Information Objects connected to an Information Ports described
above. The parameter “work”, of which the value is of type Real, and the dimensionality
corresponding to Watt (i.e. [m = 2, kg = 1, S = -3, A = 0, K = 0, mole = 0, …] representing kg
m2 s-3, see “Open Interface Specification: Parameter Common Interface”) is always part of an
Energy Object. In addition to that additional parameters can be present depending on the type of
energy that is being transported, as listed in table 2-5.

Do I understand correctly that the object to connect would be of CapeCollection<CapeParameter> class?

Using the COBIA class wizard I created a new class and implemented the mentioned interfaces in the specification. It is inheriting the following adapters:

Code: Select all

class EnergyPort :
	public CapeOpenObject<EnergyPort>,
	public CAPEOPEN_1_2::CapeIdentificationAdapter<EnergyPort>,
	public CAPEOPEN_1_2::CapeUnitPortAdapter<EnergyPort>,
	public CAPEOPEN_1_2::CapeCollectionAdapter<CAPEOPEN_1_2::CapeRealParameter,EnergyPort>,
	public CAPEOPEN_1_2::CapeParameterSpecificationAdapter<EnergyPort> {

Perhaps the last two are redundant since I already have a ParameterCollection and RealParameter classes. Anyhow, I am not sure how to implement the Connect method. If I try something like:

Code: Select all

void Connect(CapeInterface objectToConnect) {
	CAPEOPEN_1_2::CapeCollection<CAPEOPEN_1_2::CapeParameter> newEnergyObject = objectToConnect;
	unitValidationStatus = CAPEOPEN_1_2::CAPE_NOT_VALIDATED;
	connectedEnergyObject = newEnergyObject;
}

I get an error that no suitable user-defined conversion from CapeInterface to CapeCollection exists. I had no problem assigning CapeInterface to CapeThermoMaterial before in the MaterialPort Class. So I thought I could implement it analogously, but I seem to be mistaken. Any advice?

[jasper]

The parameter specification is indeed not implemented on the port, it should be implemented (along with ICapeIdentification) on the item(s) in the collection.

The object that connects to the port is a collection object as well, each item in that collection is the actual parameter (so will implement the parameter specification, and the real parameter interface).

I am not clear on which of the two statements is giving your error:

Code: Select all

CAPEOPEN_1_2::CapeCollection<CAPEOPEN_1_2::CapeParameter> newEnergyObject = objectToConnect;

looks ok to me, but can be written like so as well:

Code: Select all

CAPEOPEN_1_2::CapeCollection<CAPEOPEN_1_2::CapeParameter> newEnergyObject(objectToConnect);

Ah - I see what the problem is. The basic object for the collection (which differs a bit from the other objects due to the template parameter, and support for std iterators) is missing the assignment directly from CapeInterface. I have created a bug on this (https://colan.repositoryhosting.com/tra ... /ticket/81) and it will be resolved in the next update. In the mean time, please add a cast to ICapeInterface*, like so:

Code: Select all

CAPEOPEN_1_2::CapeCollection<CAPEOPEN_1_2::CapeParameter> newEnergyObject = (ICapeInterface*)objectToConnect;

Let me know in case this does not do the job for now.

[ahmedsabriz]

Thank you so much for your replay. That indeed exposed the work parameter to the energy stream. However, the value is not updated. It is always displayed as 0.

Here is what the constructor of my unit looks like

Code: Select all

Unit()  :
	name(unitName), description(unitDescription), validationStatus(CAPEOPEN_1_2::CAPE_NOT_VALIDATED), dirty(false),
	portCollection(new PortCollection(name)), paramCollection(new ParameterCollection(name)),
	energy(new EnergyPort(COBIATEXT("Energy"), CAPEOPEN_1_2::CAPE_INLET, name, validationStatus)),
	feed1(new MaterialPort(COBIATEXT("Feed 1"), CAPEOPEN_1_2::CAPE_INLET, name, validationStatus)),
	product1(new MaterialPort(COBIATEXT("Product 1"), CAPEOPEN_1_2::CAPE_OUTLET, name, validationStatus)),
	realParameter1(new RealParameter(name, COBIATEXT("Outlet temperature"), 373.15, 73.15, 1273.15,
		CAPEOPEN_1_2::CAPE_INPUT, validationStatus, dirty)),
	realParameter2(new RealParameter(name, COBIATEXT("Heat duty"), 0, -(std::pow(2, 64)), std::pow(2, 64),
		CAPEOPEN_1_2::CAPE_OUTPUT, validationStatus, dirty)),
	work(new RealParameter(name, COBIATEXT("work"), 0, -(std::pow(2, 64)), std::pow(2, 64),
		CAPEOPEN_1_2::CAPE_OUTPUT, validationStatus, dirty)) {
		[...]
}

In the constructor I added the unit parameters to their parameter collection and work to the energy interface

Code: Select all

	[...]
	paramCollection->addParameter(realParameter1);
	paramCollection->addParameter(realParameter2);
	energy->addParameter(work);
	portCollection->addPort(energy);
	[...]

My calculation method concludes with heat duty assigned to both the work parameter of the energy stream and also the unit parameter, realParameter2. I tried using the same parameter instead of two separate ones added to each collection, but I got the same results.

Code: Select all

	[...]
	realParameter2->putValue(heatDuty);
	work->putValue(heatDuty);
	[...]

And here is how the unit compares to the conventional heater:
https://user-images.githubusercontent.c ... 86c794.png


Since the heat duty is displayed correctly, the issue is clearly with my implementation of work parameter or the EnergyPort class. I am not sure what it is though.

[jasper]

If you want to predict the values on the energy stream, it must be an output stream.

Please note that the sign in work should change in that case. A positive sign on work on an inlet energy stream means energy consumed. A positive sign on work on an outlet energy stream means work produced.

Also, the parameter that actually contains work is provided by the stream object connected to the unit operation. So

- change the port to an OUTLET port
- from the object connected to the port, get the "work" parameter
- set its value
- do the same for the temperature limits, in case of a thermal energy stream

In CAPE-OPEN v1.1, the port object merely exposes a parameter specification. As in CAPE-OPEN 1.2 the parameter specification no longer exists, the port itself exposes a parameter, but the only aspects used of this parameter is the meta information (name, description, unit of measure ...)

[ahmedsabriz]

Thank you once again for the clarification. The energy stream now exposes all the parameters just as it does with the built-in heater (at least it appears so). I can now comfortably move on to practise with more complicated units.

[jasper]

Glad to hear it works.