"station NN.SSS is already defined" error
luca-s opened this issue · 12 comments
Dear developers,
I have a station 8D.BT176, which has two location codes A and B that I would like to map in Seiscomp to 2 separate station codes (BT176 and BT177), different network code (8R) and strip location codes. To summarize this is the mapping I would like to have:
- 8D.BT176.A.FP[1,2,Z] - > 8R.BT176..FP[1,2,Z]
- 8D.BT176.B.FP[1,2,Z] - > 8R.BT177..FP[1,2,Z]
The chain plugin seems to have all the options I need, but when I start seedlink I get the following error:
Fri Nov 11 14:06:22 2022 - seedlink: SeedLink v3.3 (2022.096) started
Fri Nov 11 14:06:24 2022 - chain0: SeedLink Chain Plugin v2.0 (2021.284) started
Fri Nov 11 14:06:24 2022 - chain0: /home/sysop/seiscomp/var/lib/seedlink/chain0.xml:24: station 8D.BT176 is already defined
I checked the code and I see why the error is raised. However I don't see why this configuration should be a problem, why cannot I have two seiscomp station codes that connect to the same physical station via seedlink? Shouldn't the code check for duplicate out_network, out_name instead of duplicated in_network, in_name ?
These are the seedlink bindings I used:
8R.BT176 station:
8R.BT177 station:
And this is the /home/sysop/seiscomp/var/lib/seedlink/chain0.xml file
<?xml version="1.0" standalone="yes"?>
<!-- Generated at Fri Nov 11 14:02:21 2022 - Do not edit! -->
<!-- template: /home/sysop/seiscomp/share/templates/seedlink/chain/chain_head.tpl -->
<chain
timetable_loader="/home/sysop/seiscomp/bin/load_timetable 127.0.0.1:18000"
overlap_removal="initial"
multistation="yes"
batchmode="yes"
netto="300"
netdly="10"
standby="10"
keepalive="0"
seqsave="60">
<group address="xxxxxxxx:18000"
seqfile="/home/sysop/seiscomp/var/run/seedlink/xxxxxx:18000.seq"
lockfile="/home/sysop/seiscomp/var/run/seedlink/xxxxxx:18000.pid"
batchmode="yes">
<station id="8R.BT176" name="BT176" network="8D" out_network="8R" selectors="A????">
<rename from="A????" to="???"/>
</station>
<station id="8R.BT177" name="BT176" out_name="BT177" network="8D" out_network="8R" selectors="B????">
<rename from="B????" to="???"/>
</station>
</group>
</chain>
I don't remember exactly, but the issue is known and I think there was some reason it was implemented right this. You will need 2 chain instances. Would something like this work:
sources = chain0:chain, chain1:chain
sources.chain0.selectors = "A????"
sources.chain1.selectors = "B????"
etc.
Thank you for the answer @andres-h , but where exactly should I set these settings? Also, does that mean I have to manually edit what is generated by seiscomp after I run seiscomp update-config?
does that mean I have to manually edit what is generated by seiscomp after I run seiscomp update-config?
No, that can always be done as a workaround, but it is not supposed to be required.
I meant bindings (key file). You can enter this using scconfig also. But I'm afraid this would not work, because you split one station into two different stations instead of joining two stations into one (more common use case). Possibly your use case is not yet supported. I'm also wondering if that check in chain_plugin.cc is really needed and can't be just removed...
I have actually found that the issue is due to the setup.py for chain plugin. Please see this PR #9
I don't have the experience with seedlink to fully understand the implications of this change, but from the code it looks like a bug. Maybe the renaming options were added as a second step and the setup.py was not fully updated.
Does your fix work as intended by you? Can you post the important change of the generated chain.xml?
I suppose that your fix will generate a new chain group with the same station and therefore will open two connections with the source seedlink server (which is probably no problem). The station attribute is actually the station to subscribe to at the source seedlink and it there can only be one entry in one group. The grouping is currently based on the target station name and that is the issue you have hit. The configuration as outlined by @andres-h should also work because it does bascially the same thing but more explicitly. I am fine with that change as it should not affect the plugin when renaming is not being used.
Does your fix work as intended by you? Can you post the important change of the generated chain.xml?
Yes, the change makes so that two chain files are generated.
File seiscomp/var/lib/seedlink/chain0.xml:
<?xml version="1.0" standalone="yes"?>
<!-- Generated at Fri Nov 11 18:19:50 2022 - Do not edit! -->
<!-- template: /home/sysop/seiscomp/share/templates/seedlink/chain/chain_head.tpl -->
<chain
timetable_loader="/home/sysop/seiscomp/bin/load_timetable 127.0.0.1:18000"
overlap_removal="initial"
multistation="yes"
batchmode="yes"
netto="300"
netdly="10"
standby="10"
keepalive="0"
seqsave="60">
<group address="xxxxx:18000"
seqfile="/home/sysop/seiscomp/var/run/seedlink/xxxxx:18000.seq"
lockfile="/home/sysop/seiscomp/var/run/seedlink/xxxxx:18000.pid"
batchmode="yes">
<station id="8R.BT176" name="BT176" network="8D" out_network="8R" selectors="A????">
<rename from="A????" to="???"/>
</station>
</group>
</chain>
File seiscomp/var/lib/seedlink/chain1.xml:
<?xml version="1.0" standalone="yes"?>
<!-- Generated at Fri Nov 11 18:19:50 2022 - Do not edit! -->
<!-- template: /home/sysop/seiscomp/share/templates/seedlink/chain/chain_head.tpl -->
<chain
timetable_loader="/home/sysop/seiscomp/bin/load_timetable 127.0.0.1:18000"
overlap_removal="initial"
multistation="yes"
batchmode="yes"
netto="300"
netdly="10"
standby="10"
keepalive="0"
seqsave="60">
<group address="xxxxx:18000"
seqfile="/home/sysop/seiscomp/var/run/seedlink/xxxxx:18000.1.seq"
lockfile="/home/sysop/seiscomp/var/run/seedlink/xxxxx:18000.1.pid"
batchmode="yes">
<station id="8R.BT177" name="BT176" out_name="BT177" network="8D" out_network="8R" selectors="B????">
<rename from="B????" to="???"/>
</station>
</group>
</chain>
I suppose that your fix will generate a new chain group with the same station and therefore will open two connections with the source seedlink server (which is probably no problem).
Exactly
Although we can accept your PR, the bindings with scconfig should be pretty easy to manage. Just add a new chain source and give it a name like chain1. You can do that in scconfig for testing. Then configure for each source (chain plugin) the station mapping individually.
Just add a new chain source and give it a name like chain1. You can do that in scconfig for testing. Then configure for each source (chain plugin) the station mapping individually.
I believe this is what I tried and it didn't work. Maybe I made a mistake or I am not understanding your comment. Could you please check the screenshots I posted at the top of this issue and tell me what I should do differently?
In the screenshot you can see that I created a a separate chain source for each station. The profile is called profile for both stations, but they are two separate bindings. I also tried calling them profile1 and profile2, but there is no difference in the results.
For clarity, these are the bindings I have. Without the PR #9 I get a single chain0.xml file (the one posted at the top of this issue).
File seiscomp/etc/key/seedlink/station_8R_BT176
sources = profile:chain
sources.profile.address = xxxxx
sources.profile.selectors = A????
sources.profile.station = BT176
sources.profile.network = 8D
sources.profile.channels.rename = A????:???
File seiscomp/etc/key/seedlink/station_8R_BT177:
sources = profile:chain
sources.profile.address = xxxxx
sources.profile.selectors = B????
sources.profile.station = BT176
sources.profile.network = 8D
sources.profile.channels.rename = B????:???
I see, my bad. You have two different stations locally so having multiple sources in one binding does not work of course. So using the source station as a key is the right thing to do.