Pipe status problem

[DanielaBS1]

I have imported an .inp file to WNTR where some pipes are meant to have a check valve (CV). On WNTR, when I query node attribute (wn.query_link_attribute('initial_status')) all pipes show initial status as 1 (open). I did expect the pipes with “CV” to have initial status as 3. When I open the same inp file on Epanet software the CVs are there!
I need to change the initial status of quite a few pipes from CV (3) to open (1). I have done:
for name in wn.pipe_name_list:
if "NP" in name:
pipe= wn.get_link(name)
pipe.initial_status="Open"
status=wn.query_link_attribute('initial_status')
Here, if I change the status to open, closed or CV it does show on the list ‘status’ correctly (0,1, 3). However, when I open the inp file on the software the pipes that had CV initially still have it !
So, I have two questions:

1. Why is the initial_status of all pipes shown as open (1) if some of them clearly have a CV on them?
2. When I change the status on WNTR and then query the status, it shows it changed correctly. But, when I open the saved inp file on Epanet software, nothing is changed (I have also added some pipes and nodes to the model and this are shown correctly, only the pipe status is not shown correctly).
   Could you please advise ?

I am using spyder 5.4.3

Thanks

[kbonney]

Hi @DanielaBS1,
Check valve and initial status are treated as two different attributes in WNTR. If you query for check_valve rather than initial_status, you should see what you are expecting. In the same way, the check_valve attribute is what you will want to modify so that your changes are reflected in the INP file you write out.

[DanielaBS1]

Thanks @kbonney
This should've solved my problem, however it didn't. Maybe I am writing the INP file incorrectly, or I am missing something else. I tell you all the steps I have taken.

I have split some pipes that had CV status :
(after defining the variables...)
for i,j,z in zip(range(len(pipe_to_split)),range(len(pipe_name_list)), range(len(junction_name_list))):
wntr.morph.link.split_pipe(wn, pipe_name_to_split=pipe_to_split[i], new_pipe_name=pipe_name_list[j], new_junction_name=junction_name_list[z],add_pipe_at_end=False, split_at_point=0.5, return_copy=False)

Then, I want some of the split pipes that have CV, not to have it. So as you suggested I did:

for name in wn.pipe_name_list:
if "NP" in name:
pipe= wn.get_link(name)
pipe.check_valve="False"
status=wn.query_link_attribute('check_valve') # This is just for checking and it shows it correctly the pipes with or without CV#

And them I save an INP file so I can see it all on EPANET software:
wntr.network.write_inpfile(wn,filename='G_modificado_teste.inp')

When I open the INP file created, the split pipes are shown correct, but the status of those pipes (named NP) I wish not to have a CV isn't.

If you could advise me, I will be very thankful.

PS. When splitting the pipes I have selected not to return a copy ( return_copy=False) as I am not sure how WNTR deals with this copy. If I select it to return a copy ( return_copy=True) then I ca not see the split pipes on the INP file created. If you could advise on that too it will be much appreciated.

[kbonney]

I identified two issues in your comment:

1. Updating check_valve on a pipe is not reflected in your inp file
2. Different io behavior depending on return_copy option

To 1., I was not able to replicate this on a basic network. I am able to successfully split pipes and change check valve status, and these changes show up in the INP file I write afterwards. If you want to provide your model and script that this issue is occuring on, or replicate the issue using a WNTR example model, I can try to take a look.

To 2., many WNTR functions have the option return_copy. When this is true, the function will return a copy of the network with whatever update that the function performs. In this case it is necessary to capture the output of the function in a variable in order to use the result. When the option is false, then the update is performed directly on the network that is passed into the function so it isn't necessary to capture the output in a new or existing variable. In other words, the behavior you observed is correct and intended.

[DanielaBS1]

Hi @kbonney

I have deleted my last message to you as I have just found out what I was doing wrong!
When specifying the valve status I had False as a string (pipe.check_valve="False") and of course it is a bool. I got it mixed up as when using pipe.initial_status before "CLose" and "Open" are strings.
I am not sure why it did not come up with an error message though!

Many thnaks!